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From  the  Sponsor 


Developing  Our  Software  Human  Capital 


The  articles  in  this  issue  of  CROSSTALK  discuss  the  human  side  of 
our  software  development  processes,  and  are  part  of  a  very  impor¬ 
tant  dialogue.  The  DoD  develops  and  delivers  to  our  soldiers,  sailors, 
marines,  and  airmen  incredibly  effective — but  increasingly  complex — 
weapons  systems.  Software  has  become  such  an  integral  part  of  these  sys¬ 
tems  that  it  is  virtually  impossible  to  find  a  weapons  system  today  that 
does  not  contain  mission-critical  software  at  its  core. 

As  the  complexity  of  our  systems  has  increased,  so  has  the  need  for  effective 
systems  and  software  engineering  throughout  the  life-cycle.  We  face  challenges  in 
implementing  robust  system  and  software  processes  starting  with  requirements 
identification  and  analysis,  through  technology  and  architecture  selection  and 
assessment,  analysis,  and  coordination  of  complex  system  design,  development, 
and  execution,  to  the  delivery  of  rigorously  tested  production  systems  with  a  full  complement 
of  hardware  and  software  capabilities.  Our  greatest  challenges,  however,  may  be  in  our 
approaches  to  building  great  people  and  teams:  recruiting,  growing,  and  maturing  systems  and 
software  engineering  professionals  who  will  successfully  deliver  today  and  tomorrow’s  critical 
defense  systems. 

Current  development  programs  are  already  challenged  to  find  the  highly  skilled  systems  and 
software  engineers  we  need,  and  numerous  studies  have  raised  concerns  about  our  capability  to 
meet  our  future  human  capital  needs.  The  DoD  is  seeking  to  address  this  challenge  in  the  near- 
term  through  improvements  in  the  training,  retention,  and  management  of  our  workforce.  New 
development  methodologies,  models,  and  tools  offer  promise  in  increasing  the  effectiveness  and 
efficiency  of  our  technical  teams.  Perhaps  most  importantly,  we  are  continually  looking  at  new 
ways  to  share  our  sense  of  excitement,  purpose,  and  professional  pride  with  the  next  generation 
of  systems  and  software  engineers. 

The  articles  in  this  issue  offer  a  range  of  viewpoints  and  thought-provoking  insights  about 
the  human  side  of  our  software  development  and  acquisition  processes.  They  present  a  look  at 
current  challenges  as  well  as  innovative  ideas  while  supporting  a  common  theme:  Managing  the 
human  side  of  our  process  is  essential  to  delivering  the  best  possible  systems  for  the  warfight¬ 
er.  I  thank  the  authors  for  their  ideas  and  hope  readers  find  this  issue  of  CROSSTALK  inter¬ 
esting  and  informative. 
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Influencing  Software  Competencies 
Across  the  DoD  Acquisition  Workforce 


Don  Scott  Lucero 

Office  of  the  Director  of  Defense  Research  and  Engineering 

The  growing  importance  of  software  in  delivering  military  capabilities  to  the  wa  fighter  increases  the  need  for  the  DoD  to 
identify  and  support  software-specific  competencies  for  the  acquisition  workforce.  To  help  address  this  challenge,  the  Software 
Acquisition  Training  and  Education  Working  Groip  (SATEWG)  is  defining  competencies for  each  acquisition  career field, 
and  reviewing  software  acquisition  curricula  against  these  competencies.  This  article  provides  insight  into  the  problems  being 
addressed,  the  SATEWG ’s  approach  to  these  challenges,  and  their  accomplishments  to  date. 


The  complexity  and  criticality  of 
defense  software  poses  a  significant 
challenge  to  the  acquisition  workforce  as 
well  as  the  human  capital  experts  who 
need  to  ensure  that  the  workforce  has  the 
right  competencies  to  deliver  this  essential 
capability  to  the  warfighter.  Add  to  this 
the  task  of  identifying  cross-functional 
software  competencies  that  are  critical 
for  acquisition  professionals,  and  you 
have  the  primary  challenges  facing  the 
SATEWG. 

There  have  been  a  number  of  initia¬ 
tives  aimed  at  improving  DoD  acquisi¬ 
tion  outcomes  over  the  years,  which 
have  subsequently  impacted  the  acquisi¬ 
tion  workforce.  In  the  mid-’90s,  the 
DoD  adopted  a  policy  encouraging  the 
use  of  commercial  products — rather 
than  those  developed  to  military  specifi¬ 
cations — in  order  to  take  advantage  of 
the  innovation  available  in  the  commer¬ 
cial  marketplace.  Commercial  standards 
became  preferred  over  military  stan¬ 
dards.  The  government  moved  toward 
specifying  the  expected  performance  of 
a  system,  rather  than  telling  contractors 
how  to  build  it. 

In  the  ’90s  era  of  declining  defense 
budgets,  policymakers  expected  acquisi¬ 
tion  reform  to  bring  about  greater  effi¬ 
ciencies  in  order  to  pay  for  defense 
acquisition.  The  Federal  Acquisition 
Reform  Act  (FARA)  of  1996  called  for 
greater  efficiencies  in  defense  acquisi¬ 
tion  [1],  The  FARA  eliminated  15,000 
members  of  the  defense  acquisition 
workforce,  and  called  for  reductions  of 
25  percent  over  the  following  five  years. 
The  focus  of  the  defense  acquisition 
workforce  shifted  ostensibly  from  engi¬ 
neering  of  systems  to  systems  acquisi¬ 
tion.  The  numbers  of  acquisition  per¬ 
sonnel  dwindled  and  systems  became 
larger  and  more  complex,  creating  sig¬ 
nificant  challenges  for  defense  acqui¬ 
sition.  These  challenges  were  thrown 
into  the  spotlight  by  Government 


Accountability  Office  (GAO)  annual 
audits  [2]. 

The  acquisition  reform  pendulum 
started  swinging  the  other  way  when,  in 
2003,  the  DoD  started  an  effort  to  rein¬ 
vigorate  systems  engineering  in  defense 
acquisition.  In  2009,  the  Secretary  of 
Defense  proposed  hiring  20,000  new 
acquisition  professionals  by  the  year 
2015  [3].  The  Weapon  Systems  Acqui¬ 
sition  Reform  Act  of  2009  established 
new  Directors  for  Systems  Engineering 


“The  application  of 
modern  software 
technologies  and  the  use 
of  sound  software 
engineering  practices  ... 
are  important  elements 
of  program  execution.  ” 

and  Developmental  Test  and  Evaluation 
and  called  for  reports  on  these  parts  of 
the  defense  acquisition  workforce  [4]. 
The  challenge,  however,  continues  to  be 
that  software  engineering  is  not  current¬ 
ly  designated  by  a  standalone  occupa¬ 
tional  career  code,  nor  is  it  managed 
within  the  acquisition  workforce  as  its 
own  career  field. 

The  evolution  of  acquisition  policy 
has  had  a  significant  impact  on  the 
acquisition  workforce  and  their  ability  to 
manage  software  acquisition. 

Software-Specific  Human 
Capital  Challenges 

Software  is  a  unique  and  critical  compo¬ 
nent  in  the  products  of  DoD,  and  its 


reach  extends  across  the  acquisition 
career  fields  and  each  of  the  services  at 
varying  levels.  The  application  of  mod¬ 
ern  software  technologies,  and  the  use  of 
sound  software  engineering  practices 
over  the  acquisition  life  cycle,  are  impor¬ 
tant  elements  of  program  execution. 

The  DoD  conducted  the  first  phase 
of  a  software  industrial  base  study  in 
2006  [5],  finding  that  their  dependence 
on  larger,  more  complex  software  is 
increasing  the  risk  of  not  delivering  sys¬ 
tems  on  schedule  and  within  budget. 
Although  the  study  found  that  the 
nation’s  overall  number  of  software 
developers  was  adequate  for  the  near- 
term,  it  found  shortfalls  in  the  number 
of  top-tier  software  program  managers, 
architects,  and  domain  experts — with 
perhaps  as  few  as  500  having  the  skills  to 
develop  the  DoD’s  complex,  software¬ 
intensive  systems.  Though  the  software 
industrial  base  study  did  not  address  the 
acquisition  workforce  per  se,  it  is  safe  to 
say  that  these  shortfalls  in  top-tier  talent 
are  evident  there  as  well. 

It  should  be  noted  that  subsequent 
phases  of  the  software  industrial  base 
study  found  shortfalls  in  the  number  of 
adequately  trained  software  developers, 
which  was  the  primary  reason  the  Office 
of  the  Secretary  of  Defense  (OSD)  — 
Acquisition,  Technology  &  Logistics 
(AT&L)  sponsored  development  of  a 
reference  curriculum  for  graduate  study 
of  software  engineering  [6]. 

In  [7],  the  National  Defense  Indus¬ 
trial  Association  (NDIA)  recommends 
actions  including  the  broadening  of 
expertise  “to  enhance  cross-functional 
and  domain  knowledge  and  skills.”  It  is 
critical  that  the  DoD  begin  identifying 
and  embedding  the  basic  software  skills 
needed  for  each  career  field.  This  will 
reduce  the  reliance  on  software  experts 
while  increasing  the  overall  abilities  of 
the  acquisition  workforce. 

In  2006,  the  Navy  started  the 
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Software  Process  Improvement  Initia- 
rive  (SPII),  which  identified  and  exam¬ 
ined  issues  preventing  software-inten¬ 
sive  projects  from  meeting  schedule, 
cost,  and/or  performance  goals  [8],  A 
survey  conducted  as  part  of  the  SPII 
effort  found  that: 

•  There  is  a  lack  of  adequately  educat¬ 
ed  and  trained  software  acquisition 
professionals  and  systems  engineers. 

•  There  are  no  established  education 
standards. 

•  Key  staff  experience  levels  are  below 
average. 

In  [8],  the  SPII’s  Human  Resources 
Focus  Team  recommended  identifying 
the  software  acquisition  training  needs 
tailored  to  the  respective  roles  and 
responsibilities  for  six  acquisition  career 
fields:  program  management,  systems 
and  software  engineering,  acquisition 
logistics,  contracting,  legal,  and  test  and 
evaluation  engineering.  They  also  rec¬ 
ommended  that  the  DoD  use  the  find¬ 
ings  of  the  report  as  a  baseline  to  ana¬ 
lyze  the  software  competencies  and 
training  of  the  acquisition  workforce  [8] . 

In  February  2008,  the  DoD  estab¬ 
lished  the  SATEWG  to  develop  soft¬ 
ware  competencies  for  the  entire  acqui¬ 
sition  workforce — not  just  software 
experts — starting  with  program  man¬ 
agers  and  systems  engineers  [9].  In  addi¬ 
tion,  the  SATEWG  was  chartered  to 
develop  and  initiate  a  plan  to  address  the 
gaps  in  the  existing  software  acquisition 
curricula.  The  SATEWG  is  comprised 
of  individuals  from  different  organiza¬ 
tions  with  the  goal  of  promoting,  across 
the  DoD,  collaboration  focusing  on 
software  and  human  capital  initiatives 
for  the  acquisition  workforce. 

SATEWG  Membership 

The  SATEWG  is  comprised  of  repre¬ 
sentatives  from  organizations  designated 
by  the  Under  Secretary  of  Defense 
(AT&L),  and  others  including  the  OSD, 
Army,  Navy,  Air  Force,  Defense 
Acquisition  University  (DAU),  Air  Force 
Institute  of  Technology,  SEI,  and 
Sevatec,  Inc. 

Each  of  these  organizations  plays  a 
role  in  developing  or  supporting  compe¬ 
tencies  and  curricula,  and  their  active 
participation  has  been  critical  to  the  suc¬ 
cess  of  the  group.  The  diversity  of  these 
stakeholders  has  made  for  a  stronger 
product.  There  are  two  types  of 
SATEWG  members:  core  team  mem¬ 
bers  and  advisors.  This  structure 
encourages  leadership  involvement  and 
provides  flexibility  for  varying  levels  of 
commitment. 


Developing  a  Software 
Competency  Framework 

A  key  challenge  for  die  SATEWG  was  to 
identify  aspects  of  software  engineering 
diat  are  truly  unique  to  software  and  rele¬ 
vant  to  the  broader  acquisition  workforce. 
For  example,  courses  often  address 
requirements  management  and  configura¬ 
tion  management,  but  they  do  not  neces¬ 
sarily  take  into  account  die  volatility  of 
software  requirements  or  the  potential  for 
spawning  a  multitude  of  slighdy  different 
software  configurations. 

Another  challenge  for  the  SATEWG 
was  to  identify  aspects  of  software  acqui¬ 
sition  general  enough  to  be  considered 
critical  by  the  broader  acquisition  work¬ 
force,  yet  specific  enough  to  support 
building  an  interdisciplinary  software  skill- 
set.  This  interdisciplinary  software  skill  set 
reduces  dependency  on  software  experts, 
which  in  turn  becomes  more  important  as 
die  acquisition  workforce  grows. 

The  SATEWG  created  an  overarch¬ 
ing  body  of  skills  called  the  software 
competency  framework.  It  is  used  as  the 
foundation  for  providing  input  to  the 
competency  models  specific  to  each 
acquisition  career  field,  and  as  a  source 
for  analyzing  existing  curricula.  During 


the  framework’s  development,  the 
SATEWG  reviewed  234  software  com¬ 
petencies  and  790  competency  elements 
from  the  following  sources: 

•  Existing  DAU  curricula. 

•  Competency  studies  and  reports 
conducted  by  the  services  (e.g.,  SPII) 
[8], 

•  Industry  best  practices. 

•  Existing  competency  models  such  as 
the  Software  Engineering  Body  of 
Knowledge  [10];  Systems  Planning, 
Research,  Development  and  Engi¬ 
neering  (SPRDE);  program  manage¬ 
ment;  and  IT  career  fields. 

The  framework  includes  the  compe¬ 
tencies  that  are  both  unique  to  software 
and  cross-functional  in  nature,  so  they 
can  be  generalized  for  the  various  acqui¬ 
sition  career  fields.  Many  software-relat¬ 
ed  competencies,  although  important, 
weren’t  deemed  by  the  SATEWG  as  dif¬ 
ferent  enough  from  the  other  disciplines 
to  be  included  in  the  framework — at 
least  from  the  perspective  of  the  acqui¬ 
sition  workforce.  For  example,  software 
specifications  are  certainly  different 
from  typical  system  specifications;  how¬ 
ever,  the  process  for  managing  these  dif¬ 
ferent  types  of  specifications  is  quite 
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similar  for  the  acquisition  workforce. 

The  SATEWG  also  reviewed  the 
persistent  software  development  and 
acquisition  issues  to  ensure  that  the 
competencies  identified  are  relevant  to 
the  pressing  needs.  This  review  included 
the  original  1968  NATO  efforts  defining 
software  engineering  [1 1]  as  well  as  the 
top  software  issues  identified  by  the 
NDIA  [12].  The  most  current  source 
turned  out  to  be  a  systemic  analysis  of 
software  issues  found  in  DoD  reviews 
of  acquisition  programs  [13]. 

Components  of  the  Framework 

The  SATEWG  framework  consists  of 
the  following: 

•  Knowledge  Areas  (4):  High-level 
descriptions  of  the  overarching  skills 
that  make  up  the  software  elements 
of  the  job. 

•  Competencies  (29):  Definitions 
that  provide  information  at  a  gener¬ 
alized  level  that  allows  flexibility  for 
cross-functional  comparison.  Com¬ 
petencies  describe  the  job  require¬ 
ments  and  individual  capabilities  at  a 
broader,  more  process-oriented  level 
than  a  single  knowledge,  skill,  or  abil¬ 
ity.  There  are  multiple  competencies 
under  each  knowledge  area. 

The  SATEWG  decided  not  to  identi¬ 
fy  the  specific  performance  outcomes 
for  each  competency  (i.e.,  the  behav- 
ior[s]  an  employee  must  demonstrate  for 


successful  job  performance).  These 
expected  outcomes  will  vary  from  career 
field  to  career  field.  Instead,  the 
SATEWG  decided  that  the  performance 
outcomes  should  be  defined  by  the 
groups  that  manage  each  career  field. 

The  framework  contains  software 
knowledge  areas  and  competencies  with¬ 
in  each  knowledge  area  (see  Table  1). 

Applying  the  Framework 

The  SATEWG  uses  the  software  compe¬ 
tency  framework  to  work  closely  with  each 
career  field  to  help  integrate  software 
expertise  into  their  existing  competency 
models. 

The  SATEWG  started  working  with 
the  SPRDE  expert  panel  to  integrate  soft¬ 
ware  into  their  draft  SPRDE  competency 
model.  The  SATEWG  identified  the  key 
competencies  from  a  software  perspective, 
while  the  SPRDE  expert  panel  identified 
the  key  software  competencies  from  their 
perspective.  Using  the  competency  frame¬ 
work,  die  SATEWG  and  SPRDE  expert 
panel  tailored  the  software  competencies 
to  the  needs  of  the  engineering  workforce. 
The  final  SPRDE  career  field  model  now 
contains  13  elements  that  address  soft¬ 
ware;  more  specifically,  14  of  the  frame¬ 
work  competencies  in  Table  1  (marked 
with  a  “*”)  were  mapped  to  the  final 
SPRDE  model. 

The  SATEWG  followed  a  similar 
process  for  both  the  Test  &  Evaluation 


and  Production,  Quality  &  Manufactur¬ 
ing  career  fields.  The  software  compe¬ 
tency  framework  allows  the  SATEWG 
to  provide  input  to  the  expert  panels  of 
each  career  field  that  is  consistent — as 
well  as  customized — to  the  needs  of 
each  career  field. 

The  SATEWG  has  also  started  the 
process  of  identifying  gaps  in  the  exist¬ 
ing  software  acquisition  curricula.  To 
conduct  this  analysis,  the  SATEWG  uses 
the  software  competency  framework,  as 
well  as  the  DAU’s  terminal  and  enabling 
learning  objectives  from  their  software 
acquisition  management  courses. 

Future  Direction 

While  the  SATEWG  remains  focused  on 
the  goals  outlined  by  the  original  charter, 
members  are  identifying  opportunities 
that  go  beyond  it.  These  efforts  further 
bridge  the  gap  between  current  and 
desired  software  proficiency  and  also 
reach  a  new  audience:  software  experts 
who  are  critical  in  managing  the  com¬ 
plexity  of  today’s  software -intensive  sys¬ 
tems.  Such  efforts  include: 

•  Formally  validating  the  framework. 

•  Fostering  a  learning  environment 
and  addressing  the  training  needs  of 
software  experts. 

•  Establishing  a  government-wide 
occupational  career  code  for  soft¬ 
ware  engineering. 

The  SATEWG  will  start  pursuing  these 
additional  efforts  when  the  elements  of 
the  original  charter  are  met.  Current 
goals  and  future  efforts  will  require  sup¬ 
port  and  collaboration  with  software 
and  human  capital  leaders  across  the 
DoD.  The  SATEWG  will  continue  to 
apply  a  collaborative  approach  to  ensure 
continued  success. 

The  SATEWG  welcomes  the  in¬ 
volvement  of  software  and  human  capi¬ 
tal  leaders  across  the  DoD.  Please  con¬ 
tact  the  author  if  you  would  like  to 
receive  more  information  about  the 
SATEWG’s  efforts. 

Conclusion 

Several  studies  conducted  recently  have 
highlighted  both  the  human  capital  and 
software-related  issues  facing  the  DoD. 
To  address  the  growing  concern  regard¬ 
ing  software  complexity  and  the  capaci¬ 
ty  of  the  acquisition  workforce,  the 
SATEWG  has  made  strides  to  ensure 
that  software-related  skills  are  both 
embedded  in  competency  models  and 
fostered  within  existing  curricula. 

The  efforts  of  the  SATEWG  have 
led  to  the  development  of  a  framework 


Table  1:  SATEWG  Software  Coenpetency  Framework  Summary 


Knowledge  Area 

Competencies 

1.  Software  Acquisition  and  Sustainment  Planning:  The 

activities  used  to  plan  for  the  acquisition,  development,  and 
sustainment  of  software  across  the  life  cycle. 

1 .  Software  Impact  on  Acquisition  Strategy* 

2.  Software  Planning* 

3.  Software  in  the  Work  Breakdown  Structure 

4.  Integrated  Master  Plan/Integrated  Master  Schedule 

5.  Planning  for  Software  Transition  and  Sustainment 

2.  Software  Development  Considerations:  Software 
development  is  a  process  of  defining  and  executing  software 
solutions  from  system-level  requirements,  which  have  been 
allocated  to  software.  This  includes  the  life-cycle  activities  such 
as  designing,  developing,  integrating,  and  testing  of  the 
software  components  of  a  system.  It  also  includes  design 
considerations  such  as  compatibility,  extensibility,  fault- 
tolerance,  maintainability,  packaging,  reliability,  reusability, 
security,  and  usability,  as  well  as  the  development  of 
associated  documentation. 

6.  Software  Architecture* 

7.  Software  Requirements* 

8.  Integration  of  Software  and  Systems  Engineering* 

9.  Software  Design* 

10.  Software  Development  Methodology 

11.  Software  Integration* 

12.  Software  Interface  Management 

13.  Software  Modeling  and  Simulation 

1 4.  Verification  &  Validation  of  Software 

15.  Software  in  Systems  Engineering  Plans 

16.  Software  Interoperability* 

1 7.  Software  Safety* 

1 8.  Software  Security* 

19.  System  and  Software  Engineering  Environment 

20.  Software  Trade  Studies 

3.  Software  Management:  Establishes  a  common  framework 
for  software  life-cycle  processes,  with  well-defined  terminology 
that  applies  to  the  acquisition  of  systems  and  software  products 
and  services,  to  the  supply,  development,  operation, 
maintenance,  and  disposal  of  software  products,  and  to  the 
software  portion  of  a  system. 

21 .  Software  Configuration  and  Data  Management 

22.  Software  Risk  Management* 

23.  Software  Technical  Reviews 

24.  Software  Quality  Assurance* 

25.  Software  Financial  Management  and  Estimation* 

26.  Software  Contracting  Considerations 

27.  Software  Measures* 

4.  Post-Deployment  Software  Support:  The  planning, 
sustainment,  and  management  activities  related  to  the 
performance  of  preventative,  predictive,  scheduled,  and 
unscheduled  actions  aimed  at  maintaining  or  improving 
software  performance  (e.g.,  functionality,  efficiency,  reliability, 
availability,  maintainability,  security,  and  safety). 

28.  Transition  to  Sustainment 

29.  Sustainment 
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which  lists  the  critical  software  compe¬ 
tencies  that  are  cross-functional  and  can 
be  customized  for  each  career  field  in 
the  DoD.  The  SATEWG  also  uses  this 
framework  to  review  existing  courses  to 
ensure  that  the  acquisition  workforce  is 
being  trained  in  the  necessary  areas  of 
software.^ 
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Recruiting  Software  Practitioners 
The  Importance  of  Self-Efficacy 


Dr.  Orit  Hazzan  Dr.  Tali  Seger 

Israel  Institute  of  Technology  Rstppin  College,  Israel 

Software  organisations  face  challenges  when  trying  to  recruit  highly  competent  software  practitioners  who  can  successfully  par¬ 
ticipate  in  and  contribute  to  a  cooperative  working  environment.  This  article  suggests — based  on  the  presented  research  con¬ 
ducted  in  a  large  international  communication  company — that  recruitingpractitioners  with  high  levels  of  self-efficacy  can  con¬ 
tribute  to  the  organisation  on  both  the  individual  and  team  levels.  This  article  also  describes  the  research  and  its  findings  and 
discusses  specific  recommendations  based  on  the  research. 


Self-efficacy  is  a  characteristic  that  dis¬ 
tinguishes  between  individuals  accord¬ 
ing  to  their  tendency  to  perceive  difficult 
events  as  challenging  and  to  what  extent 
they  feel  capable  of  accomplishing  almost 
any  task  [1],  Based  on  the  research  pre¬ 
sented  in  this  article,  we  suggest  consider¬ 
ing  self-efficacy  as  one  selection  criterion 
for  software  practitioners.  Recruiting 
practitioners  with  high  levels  of  self-effi¬ 
cacy  may  contribute  to  the  organiza¬ 
tion — not  only  with  individuals,  but  also 
on  the  team  and  organization  levels. 

Our  research  was  conducted  in  a  large 
international  communication  company 
located  in  Israel.  During  Phase  I,  we 
explored  for  two  job  levels  (i.e.,  senior 
versus  junior)  personal  characteristics  that 
can  predict  practitioners’  orientation 
towards  cooperative  software  develop¬ 
ment  environments,  such  as  Agile  ones. 
Self-efficacy  was  found  to  be  a  crucial  fac¬ 
tor  for  practitioners  in  senior  positions 
only  [2],  This  finding  led  us  to  focus  (in 
Phase  II)  on  how  different  levels  of  self- 
efficacy  are  related  to  software  practition¬ 
ers’  perception  of  their  working  environ¬ 
ment. 

This  article  describes  the  research  and 
its  findings  and  discusses  specific  implica¬ 
tions  derived  from  the  findings  with 
respect  to  the  recruitment  processes  of 
software  practitioners.  One  of  our  prima¬ 
ry  contributions,  we  suggest,  is  the  wider 
perspective  offered  on  self-efficacy  in  the 
context  of  software  organizations. 
Specifically,  our  research  indicates  that 
self-efficacy  is  also  related  to  software 
practitioners’  perception  of  their  work 
environment. 

Phase  I:  Job-Level  Comparison 
of  Agile  Orientation 

The  first  phase  of  the  research  (see  [2]) 
examined  how  software  practitioners’ 
personal  characteristics  are  related  to 
their  Agile  orientation.  Research  partici¬ 
pants  comprised  376  software  practition¬ 
ers  employed  in  two  divisions  of  the 


company.  In  terms  of  job  level,  the  sam¬ 
ple  included  228  experts  and  managerial- 
level  practitioners  (61  percent)  and  148 
junior-level  practitioners  (39  percent). 

The  research  variables  examined  in 
Phase  I  were: 

•  Agile  Orientation.  Agile  orientation 
was  determined  by  examining  practi¬ 
tioners’  perceptions  of  how  Agile 
software  development  takes  place  in 
practice.  It  was  measured  using  eight 
out  of  the  23  items  from  the  original 
version  of  Hazzan  and  Dubinsky’s  [3] 

“Recruiting  practitioners 
with  high  levels  of 
self-efficacy  may 
contribute  to  the 
organization — not  only 
with  individuals,  but  also 
on  the  team  and 
organizational  levels. ” 

questionnaire.  The  items  address  cus¬ 
tomer  expectations,  teamwork  habits, 
and  perceptions. 

•  Self-efficacy.  Software  practitioners’ 
level  of  self-efficacy  was  measured 
using  the  new  general  self-efficacy 
scale,  as  adapted  from  [4], 

•  Psychological  Needs.  McClelland’s 
needs  theory  [5]  and  needs  survey  [6] 
were  used.  The  needs  theory  attempts 
to  explain  and  predict  attitude  and 
behavior  based  on  an  individual’s 
internal  needs.  Software  practitioners’ 
level  of  psychological  needs  is  exam¬ 
ined  using  35  items  that  appeared  on 
the  original  version  of  the  needs  sur¬ 
vey,  addressing  the  following  five 
needs:  achievement,  dominance,  affil¬ 


iation,  difference,  and  attitudes 
toward  change. 

•  Perceived  Supervisory  and  Co- 
workers’  Support.  Software  practi¬ 
tioners’  perceptions  of  co-workers’ 
and  supervisory  support  was  mea¬ 
sured  using  26  of  the  44  items 
appearing  on  the  original  question¬ 
naire  developed  by  Halpin  and  Croft 
[7],  This  variable  includes  seven  indi¬ 
cators,  four  of  which  were  adopted 
due  to  their  correspondence  with  the 
topic  of  this  study  (software  develop¬ 
ment  environments):  cooperation, 
morale,  intimacy,  and  manager  sup¬ 
portiveness. 

All  research  variables  were  rated  on 
the  Likert  scale  (where  1  indicates  a  low 
perceived  level  of  the  measured  item  and 
5  indicates  a  high  perceived  level)1. 

Specifically,  by  using  the  structural 
equation  modeling  analysis  method  [8,  9], 
Phase  I  examined  relations  between  Agile 
orientation  and  psychological  needs,  self- 
efficacy,  and  perceived  supervisory  and 
co-worker  support  at  junior  and  manage¬ 
rial-level  practitioner  job  levels.  Main 
findings  in  this  phase  included: 

•  For  both  job  levels,  perceived  super¬ 
visory  and  co-worker  support  seem  to 
be  a  crucial  factor  that  mediates  the 
relations  between  the  individual’s  dif¬ 
ferent  psychological  needs  and  his  or 
her  Agile  orientation.  Specifically,  a 
high  level  of  perceived  support  is 
positively  related  to  a  high  level  of 
orientation.  This  finding  is  important 
since  it  has  direct  implications  for  the 
design  of  a  software  development 
environment. 

•  For  managerial-level  practitioners 
only,  a  high  level  of  self-efficacy  is 
positively  associated  with  a  high  level 
of  perceived  support  and  a  high  level 
of  Agile  orientation. 

Further  details  on  Phase  I  and  explana¬ 
tions  of  the  results  are  presented  in  [2]. 

The  fact  that  self-efficacy  is  frequent¬ 
ly  researched  in  organizational  behavior 
studies — and  that  it  appears  in  our  Phase 
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Table  1:  Summary  of  Canonical  Discriminant  Functions  and  Standardised  Canonical  Discriminant 
Function  Coefficients 


I  research  as  a  variable  that  dominates 
perceived  support  and  Agile  orientation 
only  among  managerial-level  practition¬ 
ers — led  us  to  examine  its  role  in  soft¬ 
ware  practitioners’  perceptions  of  their 
work  environment.  Such  an  examination 
suggests  that  self-efficacy  may  also  be 
indicative  of  practitioners’  perception  of 
climate  (expressed  by  their  perceived  sup¬ 
port).  In  other  words,  along  with  acting 
as  an  indicator  on  the  individual  level, 
self-efficacy  is  an  indicator  that  is  related 
to  the  team  and  organizational  levels.  The 
following  sections  elaborate  on  self-effi¬ 
cacy  and  describe  the  second  phase  of 
the  research,  where  self-efficacy  played  a 
central  role. 

Self-Efficacy 

The  concept  of  self-efficacy  has  received 
increased  attention  in  organizational 
research  over  the  past  two  decades  [10]. 
Bandura  defines  self-efficacy  as  the  “belief 
in  one’s  capabilities  to  organize  and  exe¬ 
cute  the  courses  of  action  required  to  pro¬ 
duce  given  attainments”  [1],  Thus,  the 
higher  one’s  self-efficacy  is,  the  more  like¬ 
ly  that  he  or  she  engages  and  persists  in 
task-related  behavior.  Research  showed 
that  self-efficacy  positively  predicts  job 
attitudes  [11],  training  proficiency  [12], 
and  job  performance  [13],  and  acts  as  a 
buffer  to  improve  the  negative  effects  of 
work  stressors  on  employees’  psychologi¬ 
cal  well-being  [14]. 

Self-efficacy  has  also  gained  some 
attention  in  the  software  engineering 
research,  where  it  is  addressed  mainly 
with  respect  to  competence.  For  exam¬ 
ple,  Paul  J.  Ambrose  proposed  that  in 
order  to  obtain  a  holistic  assessment  of 
competence,  it  is  essential  to  evaluate 
developer  perceptions  and  beliefs  on 
what  they  can  achieve — since  these 
beliefs  can  impact  their  performance, 
regardless  of  the  skills  the  developer 
possesses  [15].  For  this  purpose, 
Ambrose  developed  a  measure  of  devel¬ 
oper  self-efficacy  to  assess  a  critical  facet 
of  developer  competence.  In  [16],  the 
self-efficacy  model  is  used  in  the  context 
of  knowledge  sharing.  The  authors  con¬ 
cluded  that  a  software  manager  (or  other 
managers)  can  easily  look  at  the  inputs 
and  outcomes  of  the  model  and  see 
where  he  or  she  could  positively  affect 
tacit  knowledge  sharing.  The  authors  of 
[17]  investigated  factors  associated  with 
software  developers’  intention  to  reuse 
software  assets.  They  found  that  techno¬ 
logical-level  (infrastructure)  and  individ¬ 
ual-level  (reuse-related  experience  and 
self-efficacy)  factors  were  major  determi¬ 
nants  of  the  developers’  behavior. 


Phase  II:  Self-Efficacy  in 

Software  Practitioners’  Profile 

Phase  II  of  the  research  focused  on  the 
role  of  self-efficacy  in  practitioners’  per¬ 
ceptions  of  their  work  environment. 
Specifically,  we  wanted  to  determine 
whether  or  not  it  was  possible  to  distin¬ 
guish  between  practitioners  with  different 
(high  and  low)  levels  of  self-efficacy  using 
the  variables  included  in  our  research.  If  it 
is  possible,  we  could  argue  that  software 
organizations  may  benefit  from  the 
recruitment  of  practitioners  with  a  high 
level  of  self-efficacy,  not  only  on  the  indi¬ 
vidual  level  (based  on  the  general  studies 
on  self-efficacy),  but  also  on  the 
team/organization  level  (based  on  the 
results  of  Phase  I  of  our  research). 

Discriminant  function  analysis2  was 
used  to  explore  the  research  hypothesis — 
that  is,  the  ability  to  differentiate  between 
software  practitioners  according  to  their 
level  of  self-efficacy  by  relying  on  the 
other  Phase  I  variables.  In  general,  this 
analysis  method  enables  the  determination 


of  which  variables  discriminate  between 
two  or  more  groups.  The  basic  idea  under¬ 
lying  discriminant  function  analysis  is  to 
establish  whether  groups  differ  with 
respect  to  die  mean  value  of  die  variables, 
and  dien  to  use  these  variables  to  predict 
group  membership  (e.g.,  of  new  cases).  If 
the  mean  values  of  the  variables  are  sig¬ 
nificantly  different  in  different  groups, 
then  we  can  say  that  these  variables  dis¬ 
criminate  between  the  groups. 

Specifically,  given  two  groups,  the  dis¬ 
criminant  function  analysis  selects  from 
the  set  of  the  research  variables,  a  subset 
of  variables  that  significantly  distinguish 
between  the  two  groups  (significance  level 
of  at  least  p  <  .05).  In  the  case  of  a  single 
continuous  variable,  a  t  test  is  used  to 
determine  whether  or  not  a  variable  dis¬ 
criminates  between  groups;  in  the  case  of 
nominal  variables,  the  chi-square  (f/2)  test 
is  used  and  for  ordinal  variables,  and  a 
Mann- Whitney  test’  is  employed.  In  such 
cases,  the  F  value  for  each  variable  indi¬ 
cates  its  statistical  significance  in  the  dis¬ 
crimination  between  groups;  that  is,  F  is  a 


Table  2:  Classification  Results  for  Self-Efficacy  Levels 


Predicted  Level 

LOW 

HIGH 

Total 

(<  3.75) 

(>4.75) 

LOW  (<  3.75) 

47  (85.5%) 

8  (14.5%) 

55  (100%) 

HIGH  (>4.75) 

11  (13.7%) 

69  (86.3%) 

80  (100%) 
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measure  of  the  extent  to  which  a  variable 
makes  a  unique  contribution  to  die  pre¬ 
diction  of  group  membership. 

To  strengthen  the  results  of  this 
research  approach,  a  sub-sample  of  the 
376  practitioners  was  examined.  It  includ¬ 
ed  only  those  practitioners  who  could  be 
clearly  characterized  with  either  low  levels 
of  self-efficacy  (lower  than  3.75,  55  prac¬ 
titioners)  or  high  levels  of  self-efficacy 
(higher  than  4.75,  80  practitioners).  Figure 
1  presents  the  means  of  the  research  vari¬ 
ables  for  these  practitioners. 

Table  1  (see  previous  page)  presents  die 
F  values  of  our  research  variables,  calculat¬ 
ed  to  distinguish  between  software  practi¬ 
tioners  with  high  or  low  levels  of  self-effi¬ 
cacy.  It  also  shows  that  all  research  vari¬ 
ables  used  in  Phase  I  are  included  in  this  set 
of  variables;  in  other  words,  they  all  con¬ 
tribute  to  tire  discrimination  between  die 
two  groups  of  software  practitioners. 
Figure  1  reflects  dais  claim  by  illustrating 
that  for  each  research  variable,  its  mean  for 
participants  with  low  self-efficacy  is  lower 
from  its  means  for  participants  with  high 
self-efficacy.  The  logical  conclusion  from 
dais  data  is  daat  all  these  variables  con¬ 
tribute  to  dae  discrimination  between  the 
two  groups. 

Specifically,  as  Figure  1  shows,  practi¬ 
tioners  with  high  self-efficacy  tend  to  have 
a  greater  Agile  orientation  than  do  low 
self-efficacy  practitioners;  in  addition, 
high  self-efficacy  practitioners  are: 

•  More  cooperative. 

•  Have  a  greater  sense  of  morale  work¬ 
ing  with  their  team  members. 

•  Feel  daat  their  personal  relationships 
with  co-workers  are  closer. 

•  Get  better  managerial  support. 

•  Report  higher  needs  in  achievement, 
dominance,  affiliation,  and  difference. 

•  Have  better  attitudes  towards  change. 
A  close  examination  of  each  of  these  vari¬ 
ables  clearly  justifies  daeir  relative  value 


wida  respect  to  practitioners  with  low  and 
high  levels  of  self-efficacy. 

Table  2  (see  previous  page)  shows  that 
the  canonical  discriminant  function,  con¬ 
structed  by  the  discriminant  function 
analysis  by  using  the  other  research  vari¬ 
ables,  classifies  correctly  high-percentage 
of  the  practitioners  85.9  percent8  accord¬ 
ing  to  their  level  of  self-efficacy. 
Specifically,  the  function  classifies  85.5 

self-efficacy  can  also 
be  used  as  an  indicator 
of  whether  or  not  a 
practitioner  perceives  his 
or  her  environment  as 
being  supportive — a 
perception  that  is 
positively  correlated  with 
development 
environments  that 
encourage  teamwork 
and  cooperation  ” 

percent  of  the  low  self-efficacy  partici¬ 
pants  and  86.3  percent  of  the  practition¬ 
ers  with  high  level  of  self-efficacy. 
Visually,  the  numbers  in  bold  print  indi¬ 
cate  correct  classification  of  47  out  of  the 
55  practitioners  with  low  self-efficacy  and 
of  69  out  of  the  80  practitioners  with  a 
high  level  of  self-efficacy. 

Based  on  die  integration  of  the  pre¬ 


sented  results,  we  suggest  diat  since  the 
research  variables  both  help  in  distinguish¬ 
ing  between  practitioners  with  high  and 
low  levels  of  self-efficacy  and  are  relevant 
for  software  development  environments, 
it  is  appropriate  to  use  self-efficacy  as  an 
indicator  for  an  individual’s  perception  of 
his  or  her  development  environment. 

Recommendations 

We  recommend  using  self-efficacy  beyond 
its  current  role  as  an  indicator  of  practi¬ 
tioners’  performance.  Specifically,  our 
research  indicates  that  self-efficacy  can 
also  be  used  as  an  indicator  of  whether  or 
not  a  practitioner  perceives  his  or  her 
environment  as  being  supportive — a  per¬ 
ception  diat  is  positively  correlated  with 
development  environments  that  encour¬ 
age  teamwork  and  cooperation,  such  as 
Agile  software  development.  Based  on 
this  finding  we  can  suggest,  for  example, 
that  recruiting  practitioners  widi  high  lev¬ 
els  of  self-efficacy  may  contribute  to  the 
organization  on  the  individual  level  by 
recruiting  practitioners  with  high  achieve¬ 
ments  and  strong  beliefs  in  dieir  perfor¬ 
mance,  but  also  on  the  team  and  organiza¬ 
tional  level.  Accordingly,  we  propose  that 
recruiting  software  practitioners  widi  high 
levels  of  self-efficacy — an  easy-to-mea- 
sure  individual  characteristic  utilizing 
available  questionnaires — may  foster  the 
formation  of  a  supportive  work  climate. 
Needless  to  say  that  when  making  such 
decisions,  each  company  should  check 
very  carefully  its  full  set  of  considerations 
and  characteristics  and  decide  on  the 
importance  attributed  to  each  factor  in  its 
recruitment  processes.^ 
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Notes 

1.  In  addition,  two  background  vari¬ 


ables — years  of  experience  and  age — 
were  collected;  they  were  not,  howev¬ 
er,  included  in  this  analysis. 

2.  Our  description  of  the  discriminant 
function  analysis  is  partially  based  on 
<www.statsoft.com/ textbook/ dis 
criminant-  function-analysis  > . 

3.  For  more  on  Mann— Whitney  and  chi- 
square  testing,  see  <http://en.wiki 
pedia.org/wiki/Mann-whitney>  and 
<http:/ / en.wikipedia.org/ wiki/ Chi 
-square_test>,  respectively. 

4.  The  betas  are  the  coefficients  of  the 
unstandardized  discriminant  function. 
Each  subject’s  discriminant  score  is 
computed  by  entering  his  or  her  vari¬ 
able  values  (raw  data)  for  each  of  the 
variables  in  the  equation.  The  betas  are 
used  to  construct  die  actual  prediction 
equation,  which  can  then  be  used  to 
classify  new  cases.  In  our  case,  see 
Table  2. 

5.  Wilks’  Lambda  is  die  proportion  of 
total  variance  in  the  discriminant 


scores  not  explained  by  differences 
among  groups.  A  lambda  of  1.00 
occurs  when  observed  group  means 
are  equal.  A  small  lambda  indicates 
that  group  means  appear  to  differ. 
Here,  die  Lambda  of  0.52  has  a  signif¬ 
icant  value  (Sig.  <  0.001);  thus,  the 
group  means  appear  to  differ. 

6.  Eigenvalue:  A  large  eigenvalue,  as  pre¬ 
sent  in  our  case,  indicates  a  high  pro¬ 
portion  of  explained  variance  in  the 
predicted  variable  (in  our  case,  level  of 
self-efficacy). 

7.  The  canonical  correlation  is  die  multi¬ 
ple  correlation  between  die  discrimi¬ 
nant  scores  and  the  levels  of  the 
dependent  variable.  A  high  correlation 
indicates  a  function  that  discriminates 
well.  The  present  correlation  of  0.69  is 
not  very  high  (1.00  is  perfect). 

8.  Determined  by  adding  the  number  of 
employees  at  high  and  low  levels 
(47+69)  divided  by  total  practitioners 
(55+80). 
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From  Projects  to  People: 

Shifting  the  Software  Acquisition  Paradigm 


Dr.  Douglas  J.  Buettner  Lt.  Col.  Chad  Millette 

The  Aerospace  Corporation  United  States  Air  Tone 

The  amount  of  embedded  flight  software  is  growing  at  a  tremendous  rate  in  the  National  Security  Space  (NSS)  systems  under 
development  by  the  Space  and  Missile  Systems  Center  (SMC).  Problems  with  Total  System  Performance  Responsibility 
(TSPR)-era  programs  like  the  Space-Rased  Infrared  System  (SBIRS)  have  been  aligned  with  opinions  that  the  DoD  has  lost 
the  “recipe” for  acquiring  complex  space  systems.  The  software-intensive  nature  of  next-generation  space  systems  necessitates 
consideration  of  a  new  software-intensive  system  acquisition  paradigm  to  not  only  tahe  full  advantage  of  the  best  people  that 
defense  contractors  have  to  offer,  but  to  ensure  the  ability  to  engineer  and  build  these  systems  far  into  the  future. 


In  October  2006,  Lt.  Gen.  Michael 
Hamel  [1],  the  SMC’s  Program 
Executive  Officer,  briefed  the  SMC  sys¬ 
tem  software  growth  trend  to  the  National 
Defense  Industry  Association  Defense 
Software  Strategy  Summit  (see  Figure  1). 

In  [2],  Buettner  and  Arnheim 
described  the  SMC-wide  review  of  test 
issues  attributed  to  the  TSPR-era  acquisi¬ 
tion  reform  policy  changes  and  its  impacts 
on  embedded  flight  software;  also  provid¬ 
ed  were  space  computer  technology 
improvement  reasons  for  the  observed 
growth  trend.  While  the  legacy  class  of 
vehicles  (shown  in  Figure  1)  appear  to 
have  a  manageable  growth  trend,  the  soft¬ 
ware  growth  trend  for  the  future  space 
systems  (with  envisioned  systems  greater 
than  one  million  SLOC)  is  beyond  any¬ 
thing  our  space  defense  establishment  has 
had  to  grapple  with  in  the  past. 

Hamel’s  presentation  supported  a 
broad  industry  software  strategy  summit 


report  [3]  containing  the  following  recom¬ 
mendations  (among  others): 

•  Review  and  analyze  the  software  engi¬ 
neering,  acquisition,  and  life  cycle 
management  initiatives,  policies, 
processes,  and  plans.  This  should 
occur  in  service  branches  (Army,  Navy, 
and  Air  Force),  defense  agencies,  and 
in  other  organizations  such  as  the 
National  Security  Agency. 

•  Solicit  service  branch,  major  com¬ 
mand,  engineering  center,  and  Pro¬ 
gram  Executive  Office  software  life- 
cycle  management  recommendations. 

•  Define  and  publish  the  DoD’s  long¬ 
term  objectives  and  course  of  action 
with  associated  priorities  and  resources 
in  a  software  life-cycle  strategy. 

In  the  face  of  increased  software 
demand,  software  project  difficulties,  lim¬ 
ited  experienced  personnel  availability, 
varied  standards  and  processes,  and 
declining  budgets,  the  report  recommends 


that  DoD  management  staff  continue 
aggressively  focusing  on  “software  engi¬ 
neering,  acquisition,  management,  and 
human  resource  life-cycle  challenges 
through  the  application  of  resources  and 
focused  action”  [3], 

Fundamentally,  many  of  the  problems 
are  a  side  effect  of  the  DoD’s  current 
competitive  bid  acquisition  strategy.  It  is 
our  belief  that  a  number  of  the  problems 
could  be  minimized  using  a  paradigm  shift 
away  from  competing  for  the  software 
engineering  and  development  aspect  of 
these  software-intensive  contracts.  Hence, 
we  provide  supporting  arguments  and 
information  showing  that  a  number  of  the 
issues  that  we  have  faced  on  the  SBIRS — 
and  those  facing  other  software -intensive 
system  acquisitions — are  side-effects 
attributable  to  constraints  imposed  by  the 
competitive-bid  acquisition  process.  These 
constraints  stress  cost  and  schedule  from 
the  onset,  resulting  in  additional  rework 
cycles  from  the  late  discovery  of  quality 
issues.  Furthermore,  we  will  explain  how  a 
paradigm  shift  could  minimize  these 
issues  for  the  class  of  space  system  acqui¬ 
sitions  that  are  on  the  future  systems  soft¬ 
ware  growth  trend.  The  current  acquisi¬ 
tion  paradigm  involves  a  competitive  bid 
(with  software  as  a  factor)  between  teams 
of  contractors  in  response  to  a  request  for 
proposal  (RFP). 

The  Problem  With  “Best 
Value”  Bidding 

In  a  Defense  Acquisition  University 
(DAU)  course  class  exercise  (attended  by 
Millette),  students  assumed  the  roles  of 
contractors  preparing  a  bid  response  to  an 
RFP  for  a  software-intensive  system. 
Students  are  given  three  options  for  soft¬ 
ware  costs:  a  low-,  medium-,  and  high- 
cost  figure.  The  evaluation  criteria  indicat¬ 
ed  that  cost  was  not  specifically  a  criterion, 
but  it  is  certainly  always  considered. 

Having  the  development  life-cycle 
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Game  Theory  and  the  Bidder’s  Billion-Dollar  Dilemma 

Game  theory  can  be  used  to  analyze  optimal  strategies  for  action  in  competitive 
situations  with  two  or  more  players  of  the  game1.  Game  theorists  use  a  strategy 
matrix  to  analyze  each  player’s  strategies  when  they  attempt  to  take  into  account 
the  action  of  their  opponent  in  their  decision-making  process  in  order  to  maximize 
their  payoff2.  An  example  of  a  normal  form  game  matrix  with  two  distinct  strate¬ 
gies  (A  and  B )  has  Player  1  payoffs  of  OCj  for  theM  strategy  and  (3 j  for  the  B  strat¬ 
egy,  while  Player  2  payoffs  are  OC2  for  the  A  strategy  and  for  the  B  strategy: 

Player  2 


A 

B 

A 

(oq,  a2) 

(an  P2) 

B 

(Pi,  a2) 

(Pi,  P2) 

The  game  is  called  a  zero-sum  game  when  one  player’s  payoff  (win)  is  the  other 
player’s  loss.  However,  the  game  is  called  a  non-zero  sum  game  if  the  payoff  to  the 
winning  player  is  not  from  the  losing  player3. 

We  now  consider  a  case  where  an  acquisition  game  for  a  very  expensive  billion- 
dollar  satellite  system  results  in  only  two  potential  bidders,  with  the  government 
acquirer  responsible  for  setting  up  the  rules  of  the  game.  Both  bidders  have  two 
pure  strategies:  the  A  strategy  results  in  providing  a  bid  for  non-recurring  research 
and  engineering  to  build  the  system  that  incorporates  more  costly  risk  mitigation 
techniques  leading  to  a  politically  unacceptable  cost  plus  a  substantial  fee  if  they 
win;  and  a  B  strategy  that  results  in  an  acceptable  cost  plus  a  substantial  fee  if  they 
win.  If  they  lose,  they  simply  get  reimbursed  for  their  effort  to  create  a  bid. 
Mathematically  we  write: 

(OCi  =  C  +  fi)  »  (c  +  fi  =  Pi)  likewise 
((X2  =  C  +  f2)  »  (C  +  f2  =  ^2)- 

In  this  situation,  the  A  strategy  with  its  higher  cost  risk  mitigation  activities  is 
considered  a  losing  strategy.  The  highly  desired  B  strategy  solution  (in  this  case)  is 
a  Nash  equilibrium4.  Unless  both  bidders  were  required  to  include  the  cost  for 
those  risk  mitigation  activities  in  their  bids,  the  likely  outcome  is  bids  that  removed 
these  engineering  tasks. 


issues  faced  by  the  SBIRS  in  their  back¬ 
ground,  the  group  selected  the  high  soft¬ 
ware  cost  as  a  way  to  mitigate  the  overall 
software  development  risk.  The  students 
believed  that  the  high-cost  figure  would, 
combined  with  staying  under  die  life-cycle 
and  unit  procurement  cost  thresholds: 
reduce  overall  cost  and  schedule  risk;  help 
inevitable  requirements  creep,  rework,  and 
other  typical  software  cost  and  schedule 
drivers;  and  present  a  better  risk-mitiga¬ 
tion  position.  However,  when  the  other 
groups  briefed  their  analysis  of  the  pro¬ 
posal — and  specifically,  why  they  did  not 
recommend  selection — each  cited  the 
high  software  cost  as  a  negative  aspect  of 
die  proposal. 

In  the  SMC,  we  learn  this  lesson  often: 
It  is  not  in  the  contractor’s  best  interest  to 
bid  die  actual,  expected,  or  risk-sensitive 
cost,  as  die  evaluators  may  not  recognize 
this  as  a  positive  and  will  only  focus  on  die 
bottom  line.  The  contractors  we  work  with 
are  not  devious  or  intentionally  trying  to 
underbid  these  efforts  maliciously;  they  are 
simply  doing  what  they  believe  they  have 
to  do  in  order  to  secure  die  work.  If  one 
bidder  of  die  group  goes  with  die  realistic 
or  conservative  cost  estimate,  they  run  the 
risk  of  being  identified  as  not  providing 
die  best  value  bid  for  the  government. 

From  this  experience — and  some  of 
die  observed  strategies  employed  by  the 
bidders  for  the  SBIRS  program  and  oth¬ 
ers — we  conclude  that  contractors  will 
(and  do)  try  to  utilize  cost-minimization 
strategies  to  win  contracts.  If  they  are  bid¬ 
ding  on  multi-billion  dollar  systems,  cut¬ 
ting  costs  to  save  die  government  billions 
of  dollars  has  repeatedly  been  shown  to 
be  a  winning  strategy.  While  shaving  costs 
in  an  attempt  to  provide  die  government 
and  the  taxpayer  with  a  system  for  a  good 
value  is  appreciated,  it  ultimately  raises  the 
question  of  how  such  strategies  could 
impact  the  quality  of  the  NSS  mission’s 
critical  software  component  early  in  a  pro¬ 
gram’s  life  cycle. 

In  [4],  seven  different  flight  software 
projects  contained  in  an  Aerospace 
Corporation  database  are  reviewed:  Two 
remarkably  different  software  projects  are 
compared  in  detail  using  a  system  dynam¬ 
ics  model.  Chapters  focused  on  qualitative 
research  and  game  theory  provide  a  num¬ 
ber  of  insightful  government  schedule 
and  cost  pressure  strategy  impacts  on  con¬ 
tractor  quality.  Also  included  is  a  model 
showing  die  deleterious  schedule  impacts 
from  the  early  life-cycle  schedule-driven 
behavior:  minimizing  effort  in  quality¬ 
enhancing  peer  reviews  and  developer  unit 
testing  (that  is  often  perceived  by  these 
individuals  to  be  a  waste  of  time). 


Contrary  to  the  near-term  schedule-saving 
efforts  by  engineers,  the  opposite  schedule 
effect  occurs  in  die  long-run  due  to  the 
increased  time  spent  fixing  errors  that  are 
found  later  (e.g,  during  software  integra¬ 
tion  testing). 

The  application  of  game  theory  con¬ 
cepts  (see  sidebar)  suggests  how  contracts 
can  get  into  the  situation  that  TSPR  poli¬ 
cies  seemed  to  accentuate.  TSPR  policies 
both  reduced  government  oversight  lead¬ 
ing  to  contractor  decisions  contrary  to 
government’s  quality  expectations,  and 
removed  software  development  standards 
from  the  contracts.  Software  standards  are 
essential  on  contracts:  They  result  in 
development  and  test  practice  compliance 
diat  all  contractors  use  to  achieve  a  rigor¬ 
ously  engineered  software  product  with  a 
demonstrated  level  of  quality  required  by 
space  systems.  Thus,  when  it  comes  to 
software  quality,  strategies  for  bidding  low 
will  inevitably  lead  to  cost  and  schedule 
overruns. 


Reference  [4]  provides  26  specific  rec¬ 
ommendations  for  the  government  and 
contractors,  including  controversial  sub¬ 
jects  like  mandating  certifications  for  soft¬ 
ware  professionals.  However,  as  long  as  we 
continue  to  competitively  bid  software  (as 
an  integral  part  of  NSS  systems),  the  cost 
and  schedule  driven  aspects  faced  by  die 
SBIRS  program  will  persist — if  not  get 
even  worse — in  the  future.  It  is  our  belief 
that  these  issues  are  founded  in  the  gov¬ 
ernment’s  competitive  bid  approach,  there¬ 
fore  making  the  current  acquisition  model 
unsustainable — even  using  newer  model- 
based  software  development  methods  uti¬ 
lized  by  the  automotive  industry  pushing 
cars  into  die  10  million  and  100  million 
LOC  regime.  The  adoption  of  these  devel¬ 
opment  methodologies  into  embedded 
space  systems  will  undoubtedly  help;  how¬ 
ever,  due  to  the  nature  of  the  bidding 
process  for  these  unique  and  extremely 
costly  systems,  we  contend  that  they  do 
not  address  the  fundamental  issues5. 
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In  addition  to  the  TSPR  policy 
changes  that  directly  impacted  space  sys¬ 
tem  software  development  and  testing 
standards  previously  mentioned,  die  cost 
as  an  independent  variable  (CAIV)  strate¬ 
gy  was  envisioned  as  a  method  for  gov¬ 
ernment  to  control  cost  by  making  it  a 
constraint  [14].  Consider  the  impact  of 
diese  constraints  at  die  software  engineer 
level:  Tough  cost,  schedule,  and  quality 
tradeoff  decisions  need  to  be  made  when 
trying  to  hire  the  people  required  to  com¬ 
plete  the  contractually  obligated  design 
documents,  write  the  software  code,  and 
test  die  software.  In  addition,  staffing  is 
required  to  adequately  review  the  design, 
code,  and  test  products.  Experience  has 
often  shown  that  sound  engineering  judg¬ 
ment  becomes  dominated  by  what  is 
believed  to  be  good  enough. 

Hence,  we  propose  an  alternative  soft¬ 
ware  acquisition  paradigm  that  we  believe 
can  work  to  effectively  minimize  a  number 
of  these  issues:  Remove  the  competition 
for  low-cost  from  consideration  for  the 
software  component  of  the  system  acqui¬ 
sition. 

Causes  of  Project  Success — 
and  Failure 

Ivar  Jacobsen,  Grady  Booch,  and  James 
Rumbaugh  identify  software  success  fac¬ 
tors  as  dependent  on  people,  process, 
product,  project,  and  tools  [15];  it  can  also 
be  argued  diat  process,  product,  project, 
and  tools  are  also  fundamentally  depen¬ 
dent  on  people,  and  thus  people  are  central 
to  die  entire  software  problem.  While 
establishing  an  early  version  of  COCO- 
MO,  Barry  Boehm  found  diat  success — in 
regards  to  lower  costs  and  on-schedule 
delivery — was  highly  dependent  on  die 
software  team  [16].  Considering  that  con¬ 
tractors  are  forced  to  manage  and  change 
out  the  personnel  they  hire  and  retain  to 
build  our  systems  (based  on  die  contracts 
drey  are  able  to  win),  we  are  faced  with  a 
situation  where  we  are  dynamically  depen¬ 
dent  on  the  number  and  quality  of  person¬ 
nel  available  at  any  given  time.  Even  true 
A-teams  under  adverse  cost  and  schedule 
constraints  have  a  high  probability  of  sig¬ 
nificantly  overrunning  cost  and  schedule  in 
order  to  maintain  quality.  However,  pro¬ 
jects  driven  by  cost  are  not  likely  to  get  die 
best  people.  The  result  is  a  mixed  bag  of 
really  good  people  trying  to  pull  along  a 
cadre  of  less-capable  performers  diat  help 
bring  staffing  numbers  up  to  die  appropri¬ 
ate  number  the  cost/ schedule  models  sug¬ 
gest.  These  models  allow  for  dialing  in  die 

®  CMMI  is  registered  in  the  U.S.  Patent  and  Trademark 
Office  by  Carnegie  Mellon  University. 


capability  of  teams;  our  experience  from  a 
number  of  programs,  however,  shows  diat 
contractors  always  claim  diat  they  have  die 
A-team,  that  they  are  CMMI®  Level  (fill  in 
your  favorite  contractually  obligated  num¬ 
ber  here),  and  that  dieir  team  can  write  the 
software  faster  than  die  speed  of  light  widi 
virtually  no  defects.  When  the  project  is 
finally  over  (after  eidier  numerous  cost 
overruns  or  finally  being  cancelled),  these 
people  are  recycled  onto  the  next  project. 
Hence,  people — more  specifically,  the 
assignment,  organization,  and  overall  man¬ 
agement  of  people — are  the  Achilles’  heel 
of  software. 

a  properly  managed 
labor  pool  could  provide 
cost  advantages  as 
well  as  a  method  for 
identifying  and 
retaining  the  best 
engineering  talent.  ” 

Oftentimes,  projects  are  saddled  with 
die  following  problems,  all  leading  to  late 
life-cycle  schedule  and  cost  overruns: 

•  Early  life-cycle  personnel  lack  the  fun¬ 
damental  knowledge  required  to  suc¬ 
cessfully  write  requirements  or  to 
design,  build,  and  mathematically  test 
complex  real-time  satellite  control 
software. 

•  Management  does  not  appreciate  the 
need  for  following  documented  engi¬ 
neering  processes. 

•  Cost-  and  schedule-driven  decisions, 
mandated  by  government  action, 
remove  numerous  prudent  risk-mitiga¬ 
tion  steps. 

Once  upon  a  time,  we  could  hide  our 
software  foibles  behind  extremely  visible 
hardware  issues,  but  not  any  longer. 

Establishing  a  National 
Systems  Engineering 
Laboratory 

Quality  and  schedule  could  be  met  (at  least 
within  a  consistent  cost  and  schedule  mar¬ 
gin)  if  we  fundamentally  shift  our  acquisi¬ 
tion  paradigm:  from  program-by-program 
cost  and  schedule  management  to  a  focus 
on  the  quality  of  people  used  to  feed  our 
engineering  teams.  This  would  be  accom¬ 
plished  by  establishing  what  we  call  a 
National  Systems  Engineering  Laboratory 


(NSEL).  In  it,  the  private  sector  (the  big 
system  integration  and  Systems  Engi¬ 
neering  and  Technical  Assistance  contrac¬ 
tors)  are  initially  reimbursed  to  provide 
these  facilities  with  their  very  best  soft¬ 
ware  personnel  (management  and  engi¬ 
neers).  The  NSEL  would  also  be  coopera¬ 
tively  staffed  widi  selected  personnel  from 
our  universities,  federally  funded  research 
and  development  centers  (FFRDCs),  and 
government  services. 

As  new  systems  are  being  competi¬ 
tively  designed  by  select  senior  private 
sector  staff  (competing  the  hardware  and 
model-based  software  designs  based  on 
system  requirements),  they  are  supple¬ 
mented  by  NSEL  personnel  and  high- 
performing  university  students  working 
behind  strict  firewalls.  NSEL  and  student 
personnel  would  have  the  experience  and 
training  to  provide  an  initial  set  of  docu¬ 
mentation  and  prototypes  to  acquisition 
staff.  The  winning  contractors,  supple¬ 
mented  with  these  NSEL  (and  now  more 
mature)  student  personnel,  would  build, 
from  the  preliminary  design  and  proto¬ 
type,  the  final  software. 

Standard  systems  and  software  devel¬ 
opment  process  tools — such  as  the  Agile, 
Spiral,  or  incremental  models — are  used 
insomuch  as  diey  are  tailored  by  die  engi¬ 
neers  themselves  to  follow  the  best  prac¬ 
tices  brought  forth  from  industry  and 
academia,  based  on  each  system’s  size  and 
type  of  effort.  Personnel  are  trained  and 
incentivized  to  both  follow  diese  process¬ 
es  and  also  suggest  process  improvements 
as  lessons  are  learned  and  technology 
advances.  Overtime  policy  can  be  set  to 
maintain  schedule,  but  never  to  the  detri¬ 
ment  of  quality.  Incentives  are  provided  to 
ensure  creation  of  only  the  end-products 
necessary  for  designing  die  system  and  the 
documents  that  must  be  handed  off  to  the 
next  development  phase  or  as  required  to 
maintain  the  system. 

Prestige  combined  with  attractive  pay 
and  high  quality  of  life,  NSEL  site  loca¬ 
tions  can  be  used  to  attract  the  best  of 
the  best.  Contractor  payouts  are  used  to 
entice  industry  to  bring  to  the  table  for 
consideration  their  best  processes,  soft¬ 
ware  designs,  and  existing  code  used  in 
other  systems.  Once  the  final  system 
design  has  been  selected,  the  pool  of 
available  top-notch  engineers  can  draw 
from  a  wealth  of  software  designs  and 
prototype  code  to  build  the  final  flight 
code.  Existing  systems  in  use  can  draw 
from  the  same  pool  of  engineers  to 
maintain  these  systems,  as  needed. 

Another  consideration  is  utilizing  uni¬ 
versity  students  and  fresh  graduates  as  a 
significant  labor  source.  Software -inten- 
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sive  systems  are  usually  dependent  on  the 
development  and  maintenance  of  signifi¬ 
cant  specialized  software  utilities  and 
tools  to  support  the  development  effort. 
Select  students  using  an  open-source 
software  paradigm  could  interact  with  the 
top-notch  NSEL  engineers  (as  their  cus¬ 
tomers)  to  develop  the  required  tool 
suites.  While  open-source  code  in  our 
defense  systems  is  usually  fraught  with 
security  concerns,  a  properly  managed 
labor  pool  could  provide  cost  advantages 
as  well  as  a  method  for  identifying  and 
retaining  the  best  engineering  talent. 
Expanding  this  open-source  tool  suite 
support  effort  to  include  actual  system 
code  could  be  investigated  once  the  para¬ 
digm  takes  hold. 

This  alternative  paradigm  would  alle¬ 
viate  the  dilemmas  facing  prospective 
bidders  on  software -intensive  acquisition 
efforts  (exemplified  in  the  DAU  exam¬ 
ple).  Under  the  NSEL  paradigm,  under¬ 
bidding  the  software  development  cost 
would  be  unnecessary  because  it  would 
not  be  a  direct  labor  charge  to  the  con¬ 
tractor.  The  late  life-cycle  software  devel¬ 
opment  personnel  would  be  supplied  by 
the  NSEL,  and  could  tap  into  prototypes 
from  our  universities,  the  contractor 
community,  and  the  engineered  design 
for  the  target  system.  This  would  ulti¬ 
mately  lead  to  more  predictability  in  the 
cost  and  schedule  of  the  software  devel¬ 
opment  efforts,  as  the  NSEL  would 
employ  high-quality  people  using  disci¬ 
plined  processes  tailored  for  the  specific 
acquisition  underway. 

The  paradigm — that  funds  an  NSEL 
as  a  national  asset,  and  removes  the  soft¬ 
ware  cost  consideration  from  the  bidding 
process — includes  the  following: 

•  There  will  be  competition  between 
engineering  teams. 

•  Early  software  activities  will  provide 
risk  mitigation  for  the  construction 
phase  of  the  contract. 

•  Independent  government  and  sup¬ 
port  staff  will  evaluate  the  engineer¬ 
ing  designs  and  estimated  construc¬ 
tion  costs  for  the  different  systems. 

•  NSEL  staff  will  be  included  on  each 
team,  with  the  expectation  of  work¬ 
ing  in  seclusion  from  NSEL  members 
on  the  other  team. 

•  Teams  will  individually  utilize  the 
pool  of  available  sub-contractors — 
with  products  and  services  deter¬ 
mined  by  the  systems  and  software 
engineering  each  team  requires  to 
build  the  system. 

•  The  engineering  and  software  proto¬ 
typing  staff  is  selected  based  on 
merit,  capability,  and  need. 


•  Software  build  and  test  staff  is  select¬ 
ed  in  part  from  the  NSEL  staff  on 
the  losing  team  and  from  engineer¬ 
ing/software  prototyping  staff.  They 
will  test  the  constructed  software  sys¬ 
tem  or  augment  the  software  develop¬ 
ment  and  test  phase,  based  on  staffing 
requirements. 

The  predicted  end-result  is  a  higher 
quality  software  product  that  is  staffed 
with  the  best  people  available.  However, 
it  should  be  mentioned  that  the  number 
of  new  software -intensive  systems  we 
could  build  as  a  nation  would  be  con¬ 
strained  by  the  number  of  NSEL  staff. 
Yet,  we  view  this  as  an  acceptable  engi¬ 
neering  alternative  to  the  CAIV-approved 
approach  under  TSPR. 

The  NSEL  is  first  and  foremost 
tasked  with  building  and  maintaining 
quality  systems,  with  a  strong  eye  towards 
successfully  designing  and  building  cost¬ 
and  schedule-acceptable  solutions.  Under 
this  premise,  quality  staff  can,  with  time, 
create  their  own  training  and  competitive 
lairing  policies  for  their  engineering  posi¬ 
tions.  In  this  manner,  the  processes 
developed  and  promulgated  by  these  staff 
tend  (through  generations  of  engineers) 
towards  a  level  that  can  keep  up  with 
demand.  While  problems  will  undoubted¬ 
ly  arise,  this  self-contained,  continual 
learning  environment  will  foster  and  lead 
towards  solutions  for  these  issues. 

We  also  propose  that  NSEL  directors 
for  functional  areas  in  engineering  are 
hand-selected  for  prestigious  appoint¬ 
ments  from  academia,  the  FFRDCs,  and 
private  industry.  Their  hiring  will  be 
based  on  current  requirements  for  gov¬ 
ernment  positions — and  will  not  be  hired 
via  political  appointment.  The  directors’ 
primary  role  will  be  to  resolve  technical 
and  management  issues — with  the 
national  need,  which  is  always  at  the  cen¬ 
ter  of  their  decision-making  process. 

Conclusions 

An  NSEL  for  defense  acquisition  strate¬ 
gy  is  an  alternative  system  acquisition 
concept  that  is  based  on  a  grass-roots  or 
grounds-up  negotiation  between  the 
engineering  disciplines.  It  has  the  poten¬ 
tial  to  take  the  DoD  boldly  where  no  one 
has  gone  before — allowing  for  acquisi¬ 
tion,  next-generation-embedded,  soft¬ 
ware-intensive  systems.  This  grass-roots 
process  is  designed  to  provide  the  best 
quality-minded  engineers  needed  to  yield 
engineered  systems  with  a  consistent  cost 
and  schedule.  We  also  believe  that  this 
concept  is  required  to  mitigate  the  soft¬ 
ware-intensive,  system-driven  people  fac¬ 


tors  that  have  plagued  a  number  of  our 
system  acquisitions — leading  some  to 
believe  that  we  have  lost  our  space  acqui¬ 
sition  recipe  for  success.  We  acknowledge 
that  the  concept  must  pass  through  the 
normal  gamut  of  politically  driven  nego¬ 
tiations.  Hopefully,  during  this  process, 
the  concept  for  building  a  national  capa¬ 
bility  consisting  of  the  best  of  the  best — 
and  a  method  to  identify  and  retain  our 
university  engineering  talent — is  not  lost. 
We’ve  even  heard  of  an  even  more  dras¬ 
tic  strategy:  using  a  draft  to  nationalize 
our  software  development  and  system 
engineering  talent.  Short  of  this  contro¬ 
versial  and  unlikely  option,  creating  a 
prestigious  system  engineering  research 
and  development  laboratory — retaining 
and  nurturing  the  world’s  best  engineer¬ 
ing  talent — is  a  sound  method,  funda¬ 
mentally  based  on  the  talent-retention 
successes  of  our  national  laboratories. 
Our  national  goal  should  be  to  attract  the 
best  personnel  to  this  field  and  we  sug¬ 
gest  that  subtleties  such  as  funding 
details,  redundant  locations,  and  other 
issues  can  all  be  politically  negotiated  and 
worked  as  this  concept  is  matured. ♦ 
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ods  will  solve  die  well-documented 
software  development  issues  that  have 
plagued  government  acquisition.  These 
issues  are  documented  in  the  popular 
press  and  in  numerous  GAO  reports; 
see  [5,  6,  7,  8,  9,  10,  11,  and  12], 
Furthermore,  a  recent  GAO  cost  esti¬ 
mation  and  assessment  guide  docu¬ 
menting  die  best  practices  for  develop¬ 
ing  and  managing  capital  program 
costs  singled  out  the  SBIRS  as  a  case 
study  [13]. 
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Allocating  Resources  in  Multi-Project  Programs 
Lessons  Learned  from  the  Trenches 


Edward  Lari,  Dr.  Jeffrey  Beach,  Dr.  Thomas  A.  Mazzuchi,  and  Dr.  Shahram  Sarkani 

George  Washington  University 

There  have  been  significant  strides  in  the  use  of  project  management  methods  for  resource  allocation  in  single-project  programs 
in  the  DoD  environment.  Unfortunately,  when  it  comes  multi-project programs,  inter-project  resource  allocation  techniques  are 
inadequate.  The  objective  of  this  article  is  to  shed  light  on  some  of  the  challenges  program  managers  are  confronted  with  when 
allocating  resources  among  multiple  project  programs,  and  to  highlight  some  of  the  practical  solutions  that  have  been  proven 
useful  in  resolving  these  issues. 


The  past  two  decades  have  seen  an 
increase  in  the  size  and  complexity  of 
DoD  software  implementation  programs. 
This  has  been  accompanied  by  an  expo¬ 
nential  growth  in  the  number  of  multi-pro¬ 
ject  programs  in  program  managers’  port¬ 
folios.  Yet  tire  literature  on  program  man¬ 
agement  has  tended  to  be  written  with  tire 
underlying  assumption  that  die  programs 
managed  are  made  up  of  single  projects  as 
opposed  to  multi-project  programs.  In  real¬ 
ity,  this  is  not  tire  case.  Most  programs 
involve  tire  simultaneous  management  of 
multiple  projects  or  a  portfolio  of  projects 
managed  to  ensure  tire  aggregate  results  at 
dre  end  of  the  program. 

Multi-project  programs  further  add  to 
dre  level  of  complexity  of  dre  resource 
management  equation.  In  managing  large- 
scale  software  implementations,  the  success 
of  any  program  is  largely  dependent  on  dre 
effective  utilization  of  its  resources  across 
multiple  projects.  Right  from  the  initial 
stages  of  program  initiation  to  dre  final 
stages  of  delivery,  the  program  manager  is 
often  faced  with  the  complexities  of 
resource  allocation  and  its  negative  impact 
on  performance  results. 

The  Traditional  Process  for 

Resource  Allocation 

In  multiple-project  programs,  demand  for 
project  resources  typically  exceeds  its  sup¬ 
ply.  This  is  usually  dre  first  lesson  learned 
by  dre  fledgling  manager  involved  in  any 
aspect  of  dre  resource  allocation  process. 
This  has  given  rise  to  one  of  dre  basic  prin¬ 
ciples  of  project  portfolio  management:  By 
defining  dre  relative  priority  of  projects 
and  by  applying  resource  leveling  and  skill- 
set  capacity  constraints,  a  medrod  which 
allocates  resources  in  a  manner  drat  opti¬ 
mizes  dreir  enterprise  utilization  can  be 
derived.  While  this  theory  has  many  propo¬ 
nents — and  dre  principle  may,  in  fact,  be 
true — its  practical  implementation  is  usual¬ 
ly  very  challenging. 

A  review  of  traditional  medrods  of 
resource  allocation  would  illustrate  how  it 


falls  short  in  determining  the  true  enter¬ 
prise  demand  or  in  identifying  the  key 
resource  conflicts  at  dre  program  level. 
From  a  conceptual  standpoint,  there  is  a 
great  deal  of  commonality  in  dre  processes 
utilized  by  organizations  to  allocate 
resources  across  multiple  projects.  The 
tools  used  for  this  purpose,  be  it  cus¬ 
tomized  software,  spreadsheets,  tables,  or 
even  roundtable  discussions,  are  all  differ¬ 
ent.  Yet  all  traditionally  begin  with  an  algo¬ 
rithm  for  assessing  and  categorizing 
demand,  and  creating  the  proposed  book 
of  work.  Considering  drat  demand  will 
exceed  supply — and  that  the  pool  of 
resources  will  run  dry  long  before  dre  list 
of  initiatives  are  exhausted — dre  initial  step 
is  to  give  relative  rankings  for  the  different 
projects  through  a  prioritization  process. 
The  prioritization  process  is  followed  by 
building  the  master  project  schedule, 
capacity  planning,  and  high-level  resource 
assignments. 

The  prioritization  process  doesn’t 
require  complexity,  needing  only  an  esti¬ 
mate  of  expected  benefits  and  initial  costs 
to  be  effective.  For  example,  one  small  divi¬ 
sion  of  an  intelligence  organization  used 
dre  very  simplistic  yet  effective  Is  it  process, 
which  sought  answers  for  questions  such  as 
Is  it  a  project ?,  Is  it  a  realistic  estimate  of  bene¬ 
fits?,  and  Is  it  a  valid  approach  to  solving  a  prob¬ 
lem?.  Also  used  are  resource  estimate 
descriptions  such  as  Small,  Medium,  and 
Large  to  facilitate  dre  definition  of  a  pro¬ 
ject’s  cost/benefit.  These  resource  esti¬ 
mates — which  would  inevitably  be  tied  to  a 
project’s  initial  priority — were  developed 
after  a  15-minute  roundtable  review  of  dre 
proposed  solutions  by  technology  platform 
managers.  Whatever  the  method  is,  dre  net 
results  of  a  prioritization  process  are  eidrer 
an  ordinal  ranking  of  projects  or  a  group¬ 
ing  of  projects  into  Critical ,  High,  Medium, 
and  Low  categories. 

Once  the  initial  prioritized  list  of  pro¬ 
jects  is  created,  the  next  step  is  to  build  the 
preliminary  enterprise  master  program 
schedule.  The  master  schedule  establishes 
time  boundaries  for  projects  drat  are  ready 


to  go  and  need  to  be  staffed.  It  may  also 
create  placeholders  for  those  projects  drat 
should  remain  in  the  queue  until  die  next 
round  of  prioritization  occurs.  Projects 
drat  do  not  make  die  cut  are  sent  to  the  pro¬ 
ject  graveyard  where  drey  widier  away  from 
lack  of  attention  or  are  resurrected  for 
anodier  crack  at  prioritization.  Within  all 
project  portfolio  management  systems  is 
an  embedded  project  evaluation  process 
used  to  assess  die  healdi  of  the  projects  at 
various  stages  in  dieir  life  cycle.  It  is  critical 
to  ask  whether  the  project  is  still  relevant  to 
the  program’s  goals  and  objectives.  If  die 
answer  is  no,  dien  the  project  should  be 
stopped.  This  way,  the  program  manager 
ensures  that  all  resources  are  deployed 
where  drey  will  offer  die  best  return  to  die 
program  as  a  whole.  In  practice,  diis  is  one 
of  the  most  difficult  decisions  program 
managers  have  to  make,  as  reshuffling  a 
project  portfolio  will  likely  displease  die 
managers  of  diose  projects.  However,  die 
program  manager  must  always  seek  to 
globally  optimize  the  program  perfor¬ 
mance — as  opposed  to  trying  to  optimize 
each  project. 

After  the  master  program  schedule  is 
created,  die  next  step  is  to  undertake  capac¬ 
ity  planning.  Capacity  planning,  normally 
performed  by  die  platform  and  skill  set,  is 
what  makes  the  master  schedule  believable. 
Here,  die  total  resource  hours  are  deducted 
from  the  overall  capacity.  Project  managers 
are  given  dieir  projects  and — widi  the  staff 
they  believe  is  required  to  complete  those 
projects — go  through  their  initiation 
processes  widi  management’s  final  instruc¬ 
tions  regarding  the  triple  constraints:  time, 
budget,  and  quality. 

High-level  resource  assignment  follows 
capacity  planning.  During  the  resource 
assignment  stage,  die  project  managers 
provide  resources  to  die  scheduling  groups. 
While  doing  this,  die  possibilities  of  over¬ 
allocation  and  under-allocation  arise.  The 
result  of  a  specific  resource  shortfall  means 
that  die  team  will  be  asked  to  do  more  to 
eidier  cover  die  deficit  or  be  forced  to  get 
by  widi  less. 
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High-level  resource  assignments  are 
analogous  to  a  hotel  reservation.  In  soft¬ 
ware  engineering,  tire  department  or  plat¬ 
form  (e.g,  Web  development,  AS/400, 
testing)  supplying  the  resource  is  die  hotel. 
The  room  and  room  type  correspond  to 
position  (i.e.,  developer)  and  attributes  (e.g, 
manager,  senior  developer,  etc.)  of  die 
resource.  Length  of  stay  (duration  of 
assignment)  is  allocated  from  available 
inventory,  but  die  actual  room  number 
(resource  name)  is  not  yet  known.  It  will 
not  be  determined  until  die  guest  (project 
manager)  arrives  (kicks  off  dieir  project). 
The  difference  between  die  two  compar¬ 
isons  is  diat  in  the  field  of  IT,  die  project 
manager  can’t  be  upgraded  to  a  better 
room  or  compensated  widi  a  free  meal  for 
any  inconvenience.  As  mentioned,  specific 
resource  shortfalls  mean  diat  the  team  will 
be  asked  to  do  more  to  cover  the  deficit  or 
be  forced  to  get  by  with  less;  hotel  guests, 
however,  will  never  be  asked  to  share  a 
room  widi  odiers  if  the  hotel  over-books. 

Challenges  With  the 
Traditional  Approach: 

A  Case  Study 

So  if  die  resource  allocation  process — widi 
stages  such  as  prioritization,  scheduling, 
capacity  planning,  and  high-level  resource 
assignment — takes  place  under  constant 
scrutiny  and  monitoring,  dien  why  do  so 
many  programs  fail?  And  why  do  most 
analyses  of  program  and  project  failures1 
list  poor  resource  scheduling  and  planning 
as  primary  causes? 

To  plainly  illustrate  diis  point,  we  pre¬ 
sent  the  following  scenario  from  a  case 
study  encountered  by  the  audiors  in  con¬ 
sulting  assignments. 

A  software  requirements  analyst  (SRA) 
was  told  diat  for  die  next  five  weeks  dieir 
time  will  be  spent  on  a  project.  Assuming  a 
40-hour  work- week,  diis  equates  to  an  ini¬ 
tial  resource  request  of  200  hours.  At  die 
project  kickoff  meeting,  die  SRA  is  given  a 
high-level  schedule  diat  mapped  out  die 
standard  project  management  life-cycle 
milestones.  According  to  die  project  man¬ 
ager,  die  SRA’s  role  on  die  project  would  be 
limited  to  three  weeks  developing  die  func¬ 
tional  requirements  and  two  weeks  assist¬ 
ing  in  the  creation  of  die  system  design 
document.  The  project  manager  assured 
die  analyst  that  none  of  these  issues  would 
take  more  than  20  hours  a  week  during  diat 
time  period.  The  analyst  examined  die  pro¬ 
ject  schedule  and  reported  back  diat  die 
SRA  could  make  those  dates.  The  SRA 
dien  needed  to  meet  widi  three  different 
business  units  to  solicit  their  input  into  die 
document:  This  required  first  arranging 


times  to  meet  widi  the  units  individually, 
dien  finding  a  location  for  a  comprehensive 
meeting,  and  dien  using  die  knowledge  to 
prepare  documentation  on  the  existing 
process.  All  of  diose  activities  can  be  done 
in  a  week.  The  analyst  estimated  two  weeks 
for  creating  the  functional  requirements 
document,  including  time  for  walkdiroughs 
(diat  need  to  be  scheduled),  revisions,  and 
signoffs  seemed  reasonable.  As  for  the  time 
required  for  assisting  system  design,  die 
analyst  wasn’t  sure — but  two  weeks  seemed 
realistic. 

Two  days  into  die  project,  the  SRA  real¬ 
ized  die  task  estimates  were  off  significant¬ 
ly.  There  was  no  existing  documentation 
for  the  system:  That  meant  two  weeks  of 
sitting  down  with  developers  and  creating 
it.  Scheduling  die  meetings  turned  into  a 
nightmare  as  well.  There  actually  turned 
out  to  be  10  business  units  that  were  stake¬ 
holders  in  the  process — and  located 
diroughout  the  country.  Including  travel 
time  (even  meeting  face-to-face  widi  half 
die  units  and  speaking  to  the  odiers  via 
conference  call),  diis  made  crafting  an  ini¬ 
tial  draft  of  die  requirements  much  more 
dian  a  two-week  job:  four  weeks  if  every- 
diing  went  well,  six  weeks  widi  coordina¬ 
tion  issues.  To  make  matters  worse,  one  of 
die  developers  came  up  widi  a  new  idea  on 
how  to  implement  die  functionality.  Even 
though  die  SRA  had  to  wait  until  the  busi¬ 
ness  requirements  were  complete  to  make 
sure,  the  developer  confidendy  projected 
diat  his  time  would  drop  from  12  weeks  to 
diree.  The  project  manager  drought  any 
lost  requirement  time  could  be  made  up 
during  the  development,  and  continued  to 
report  the  project’s  overall  status  as  green 
(on  schedule  widiin  an  acceptable  variance 
of  planned  targets).  Needless  to  say,  die 
project  did  not  move  on  as  per  die  previ¬ 
ously  planned  project  schedule.  This  exam¬ 
ple  clearly  shows  that  in  spite  of  diorough 
planning,  something  had  gone  wrong 
somewhere. 

An  analysis  of  diis  case  study  presents 
die  following  questions: 

•  What  numbers  should  be  reflected  in 
capacity  planning  and  the  enterprise 
project  schedule? 

•  While  die  aggregate  hours  for  this  pro¬ 
ject  may  decrease,  what  will  be  die 
impact  to  die  SRA’s  pool  of  resources 
for  die  program? 

•  Where  are  die  extra  analysis  hours  sup¬ 
posed  to  come  from? 

The  theme  echoed  in  diis  scenario — 
one  repeatedly  encountered  by  project  and 
program  managers — is  diat  the  root  cause 
of  failing  to  perform  the  resource  alloca¬ 
tion  process  properly  can  be  traced  back  to 
two  specific  issues: 


1 .  The  inability  of  program  managers  and 
the  systems  diat  support  them  to  deter¬ 
mine  true  capacity. 

2.  The  failure  of  project  and  program 
managers  to  comprehend  die  impact  of 
the  program’s  critical  padi  across  multi¬ 
ple  projects. 

Alternative  Solution 
Approaches 

While  these  problems  are  solvable,  die 
solutions,  like  most  management  problems, 
are  neidier  linear  nor  discrete.  Experience 
indicates,  however,  that  a  combination  of 
approaches  will  go  a  long  way  in  solving 
the  problem. 

Determining  True  Capacity 

A  common  error  often  made  by  programs 
is  failing  to  perform  true  program  capacity 
in  the  initial  stages.  For  program  capacity 
planning  to  work,  bodi  die  supply  of  and 
demand  for  available  resources  must  be 
well-estimated.  What  may  not  be  apparent 
in  performing  this  exercise  is  how  to 
account  for  die  margin  of  error  inherent  in 
both  estimates.  This  margin  of  error  may 
or  may  not  be  factored  in  when  performing 
the  initial  resource  assignments,  but  it  has 
to  be  accounted  for  while  undertaking 
capacity  planning  at  both  the  project  and 
program  levels.  Not  only  do  calculations 
have  to  be  performed  at  the  project  levels, 
but  also  at  program  levels  so  as  to  ade¬ 
quately  estimate  program-level  risks.  By 
changing  the  way  die  future  demand  is  cal¬ 
culated  and  by  using  die  magnitude  of  pro¬ 
ject  tasks  as  an  additional  input,  managers 
can  perform  resource  allocation  more 
effectively  and  resolve  these  conflicts 
before  diey  become  full-blown  program 
risks. 

Efficient  Program  Time-Tracking 

Assuming  that  the  initial  resource  supply 
has  been  calculated  correctly,  the  real  avail¬ 
ability  of  personnel  is  determined  by  die 
projects  and  program  level.  An  employee 
working  on  multiple  projects  should  have 
the  ability  to  track  dieir  inter-project  usage 
statistics.  Unfortunately,  this  is  not  often 
the  case,  even  though  organizations  have 
deployed  various  resource  tracking  systems 
and  rigorously  track  hours  at  die  project 
and  development  life-cycle  phase  levels.  A 
typical  employee  only  receives  guidance  on 
the  percentage  of  time  allotted  and  die 
overall  number  of  hours  the  platform  has 
budgeted  for  die  project  in  question;  no 
consideration  is  given  to  die  inter-project 
utilization.  In  order  to  perform  program- 
level  time-tracking,  systems  and  processes 
that  can  track  resource  usage  both  at  the 
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Software  Human  Capital 


Software  Defense  Application 

DoD  program  managers  are  increasingly  being  tasked  with  managing  complex  software 
programs.  As  such,  the  number  of  multi-project  programs  in  die  manager’s  portfolio  is 
not  only  increasing  but  constantly  changing — a  challenge  accompanied  by  a  set  of 
unique  resource  allocation  problems  not  typically  encountered  in  single-project  pro¬ 
grams.  Unfortunately,  die  program  management  literature  has  tended  to  treat  programs 
as  if  drey  are  all  composed  of  a  single  project,  thus  ignoring  diese  challenges.  The 
objective  of  diis  article  is  to  address  die  challenges  faced  by  program  managers  in  DoD 
software  development  programs  as  they  allocate  resources  across  multiple  projects. 
This  article  will  be  especially  useful  to  DoD  program  managers  who  manage  portfolios 
of  projects,  project  managers  who  work  in  multi-project  programs,  and  software  engi¬ 
neers  and  analysts  who  support  programs  in  the  DoD  software  community. 


project  and  program-level  must  be  imple¬ 
mented.  This  may  be  as  simple  using  a 
spreadsheet  or  a  more  integrated  enter¬ 
prise-resource  planning  system. 

Program-Level  Task  Tracking 

A  specific  project  can  have  many  tasks. 
Therefore,  it  is  necessary  to  track  die  tasks 
at  die  different  levels,  project  and  program 
alike.  Project  managers  typically  conduct 
task-level  resource  tracking,  but  others 
involved  widi  the  program  rarely  get  drat 
opportunity.  The  program  manager  is  usu¬ 
ally  conditioned  to  report  on  die  resource 
pools  at  die  summary  level  and  does  not 
normally  request  information  about  them 
on  die  task  level.  While  die  program  man¬ 


ager  rarely  has  the  need,  both  die  project 
and  program  managers  should  be  equally 
aware  of  die  task  requirements  and  tracking 
to  be  undertaken  (down  to  die  task  level)  to 
avoid  unnecessary  resource  conflicts. 

As  for  accounting  for  different  types  of 
outcomes,  program/project  evaluation  and 
review  technique  (also  known  simply  as 
PERT)  formulas  can  become  an  effective 
tool  to  account  for  variances  in  resource 
estimates  at  die  program.  For  all  resources 
assigned  to  a  task: 

•  Effort  remaining  on  a  task  per  project 
=  X  Estimate  of  Hours  to  Completion 
=  X  (Pessimistic*  +  4  x  Most  likely*  + 
Optimistic*)  •*’  6 

*  Estimated  remaining  hours  for  any  task. 


•  The  total  effort  remaining  for  a  project 

resource  at  die  program  level  =  X 

Effort  remaining  on  all  project  tasks. 

•  The  total  remaining  effort  for  a 

resource  =  X  Efforts  on  all  projects  in 

the  program. 

It  should  be  noted  that  calculating 
remaining  work  estimates  by  resource,  pro¬ 
ject,  and  program  is  a  continuous  exercise 
that  should  be  included  as  a  standard  oper¬ 
ating  procedure  whenever  earned  value 
analysis  is  performed  on  an  ad-hoc  basis.  It 
may  add  some  incremental  effort  to  die 
program,  but  creating  a  task-level  feedback 
loop  ensures  that  bodi  project  and  pro¬ 
gram  managers  know  die  true  working 
capacity  of  their  resource  pools. 

Program  Resource  Critical  Path 
Analysis  (CPA) 

The  classic  definition  for  a  critical  padi  is 
the  sequence  of  project  network  activities 
that  add  up  to  die  longest  overall  duration 
in  a  project.  CPA  is  a  powerful  tool  that 
uses  mathematical  algoridims  to  schedule 
complex  project  activities.  It  is  designed  to 
provide  visibility  into  potential  project 
resource  issues  so  as  to  develop  risk-miti¬ 
gation  strategies. 

Extending  die  critical  path  concept  to  a 
set  of  related  projects  is  problematic  to  a 
lot  of  programs.  This  is  because  while  die 
application  of  CPA  in  a  single  project  is 
well  understood,  die  ability  to  extend  diis 
concept  to  multi-project  programs  is  chal¬ 
lenging.  This  is  because  performing  a  CPA 
over  multiple  projects  is  not  a  simple  activ¬ 
ity  to  complete.  It  requires  the  ability  to 
identify  die  critical  path  for  each  project  at 
a  low  enough  task  level,  a  willingness  to  cal¬ 
culate  die  true  effort  for  each  resource 
assigned  on  the  critical  task,  and  die  coor¬ 
dination  of  resources  for  critical  path  tasks 
across  die  program. 

The  coordination  of  resources  for  crit¬ 
ical  padi  tasks  across  the  program  is  para¬ 
mount  to  the  success  of  program  CPA.  A 
minor  oversight  in  coordination  could  lead 
to  cascading  resource  risks  across  the  entire 
program.  One  simple  yet  effective  method 
is  die  frequency  litmus  test  approach  to 
assessing  risks  across  a  program’s  critical 
padi.  It  states  diat  a  resource  cannot  be 
assigned  to  more  dian  two  critical  path 
tasks  in  die  same  program.  Our  empirical 
observations  confirm  that  most  technical 
resources  begin  to  lose  focus  when  dealing 
widi  more  dian  two  crises  at  die  same  time. 
And,  since  tasks  on  die  critical  path  have 
the  highest  probability  of  generating  a  true 
crisis,  every  effort  must  be  made  to  avoid 
situations  where  a  key  resource — on  critical 
padi  tasks — faces  multiple  crises  simultane¬ 
ously. 
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Conclusion 

The  blinding  pace  of  IT  innovation  and  die 
growing  complexity  of  DoD  requirements 
has  led  to  more  challenging  multi-project 
programs.  Program  managers  are  charged 
with  managing  programs  drat  are  more 
complex,  thus  requiring  intra-project  and 
inter-project  resource  utilization  manage¬ 
ment.  The  ability  to  track  and  effectively 
utilize  these  resources,  however,  requires 
effective  resource  allocation  methods. 

While  die  field  of  project  management 
has  successfully  developed  techniques  for 
managing  intra-project  resource  allocation, 
its  application  in  multi-project  programs  is 
still  inadequate.  It  requires  diligent  project 
and  program  management  skills  and  prac¬ 
tices  beyond  those  traditionally  required  in 
single-project  environments.  In  addition,  it 
requires  die  adaptation  of  best  practices — 
including  determining  program-level  true 
capacity,  efficient  program  time  tracking, 
program-level  task  tracking,  and  program 
resource-critical  CPA.  Finally,  a  concerted 
effort  is  required  to  integrate  enterprise- 
level  resource  allocation  and  management 
tools  for  program  management  so  as  to 
enable  the  intra-project  and  inter-project 
resource  allocation.  Without  this,  effective 
program  management  is  likely  to  fail.  ♦ 

Note 

1 .  There  has  been  significant  analysis  and 
discussion  of  program  and  project 
failures,  including  the  Standish 
Group’s  Chaos  Report  (see  the  1995 
incarnation  here:  <www.projectsmart. 
co.uk/ docs/ chaos-report. pdf>),  the 
Bull  Report  (1998),  and  the  KPMG 
Canada  Study  (1997). 
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Optimizing  Myers-Briggs  Type  Indicator  Training: 

Practical  Applications 

Dr.  Jennifer  Tucker 

Otto  Kroeger  Associates 

While  many  in  the  DoD  systems  development  community  have  been  exposed  to  the  Myers-Briggs  Type  Indicator  (MBTI)® 
assessment,  many  acknowledge  not  actively  applying  its  insights  to  their  work.  Ultimately,  became  every  system  begins  and 
ends  with  the  human  mind,  the  cognitive  theory  that  underlies  the  MBTI  is  directly  applicable  to  development  work  and  man¬ 
agement.  This  article  summarises  practical  ways  to  apply  the  MBTI  to  project  and  systems  management. 


Most  experienced  hands  in  die  DoD 
system  development  community 
have  encountered  the  MBTI  assessment. 
A  common  tool  for  better  understanding 
communication,  leadership,  and  teams,  the 
MBTI  has  been  administered  to  millions 
of  people  over  more  than  three  decades. 
That  means  a  lot  of  workshops,  a  lot  of 
money,  and  a  lot  of  hours. 

Despite  this,  trainers  frequently  find 
themselves  leading  MBTI  workshops 
where  most  participants  have  taken  the 
assessment  before,  but  where  few  remem¬ 
ber  the  preference  scales  or  their  personal 
type  preferences.  Even  fewer  are  able  to 
describe  how  they  have  used  type  to  better 
manage  themselves,  odiers,  and  the  pro¬ 
jects  they  lead.  A  recent  participant  at  a 
Defense  Acquisition  University  workshop 
I  facilitated  captured  it  best:  “DoD  imple¬ 
mentation  of  the  MBTI  has  historically 
been,  at  best,  suboptimal.” 

This  article  reviews  practical  and  con¬ 
crete  methods  for  applying  the  MBTI 
assessment  and  its  underlying  theory  of 
psychological  type.  An  applied  under¬ 
standing  of  psychological  type  to  solve 
problems  helps  build  better  systems  and 
can  improve  the  optimization  and  ROI  on 
MBTI  training  programs. 

Psychological  Type 

The  MBTI  assessment  is  based  on  the 
work  of  Carl  Jung,  a  Swiss  psychiatrist 
who  developed  psychological  type,  one 
of  the  most  comprehensive  theories 
explaining  human  personality.  The  psy¬ 
chological  type  model  proposes  that  we 
each  have  in  born  preferences  for  how 
we  get  our  energy,  go  about  gathering 
information  and  making  decisions,  and 
generally  orient  ourselves  to  our  world. 
The  theory  is  captured  in  the  four  scales 
of  MBTI  assessment.  Each  scale  repre¬ 
sents  a  dichotomy  of  preferences.  Just  as 
you  have  a  preference  for  writing  with 
your  right  or  left  hand,  type  theory 
asserts  that  you  have  a  preference  for 

®  MBTI,  Myers-Briggs,  and  the  Myers-Briggs  Type 
Indicator  are  registered  trademarks  of  the  MBTI  Trust, 
Inc. 


one  of  two  sides  of  each  of  the  four 
scales.  Figure  1  summarizes  the  scales 
and  the  preferences,  with  the  center 
items  being  the  dichotomies,  also  known 

as  preference  pairs. 

Too  often,  MBTI  workshops  explain 
tire  scales  and  help  people  identify  their 
preferences  on  tire  scales,  but  then  reach 
tire  end  of  the  time  allotted.  This  leaves 
little  to  no  time  to  explicitly  relate  the 

“An  applied 
understanding  of 
psychological  type  to 
solve  problems  helps 
build  better  systems  and 
can  improve  the 
optimization  and  ROI 
on  MBTI  training 
programs.” 

principles  of  psychological  type  to  the 
actual  problems  of  project  management 
and  systems  development.  Another  com¬ 
mon  occurrence  is  a  workshop  that  focus¬ 
es  purely  on  relationship  issues,  but  with¬ 
out  an  explicit  connection  between  those 
relationships  and  the  achievement  of  pro¬ 
ject  goals. 

From  Individual  Preferences 
to  Project  Performance 

The  links  between  psychological  type  and 
project  performance  are  strong.  The  way 
our  brains  function  drives  how  we  engage 
with  projects.  When  people  come  togeth¬ 
er  on  a  systems  project,  their  preferences 
play  out  together  at  the  project  level.  In 
fact,  psychological  type  preferences  can 
often  be  detected  as  specific  project-level 
patterns  that  are  either  actively  supporting 
or  threatening  success.  As  described  in  [2], 


projects  are  often  at  the  most  basic  level: 

•  Externally  facing  or  internally  facing 
(aligned  with  either  Extraversion  or 
Introversion) 

•  Fact  driven  or  possibilities  driven 
(aligned  with  either  Sensing  or 
Intuition) 

•  Product  focused  or  customer  focused 
(aligned  with  either  Thinking  or 
Feeling) 

•  Structured  or  emergent  (aligned  with 
either  Judging  or  Perceiving) 

What  follows  is  an  example  of  how 
individual  psychological  preferences  play 
out  at  a  systems  level. 

At  a  personal  level,  Judging  or 
Perceiving  relates  to  whether  we  prefer 
showing  the  world  our  decisions  or  our 
data  gathering.  Judgers  tend  to  prefer  clo¬ 
sure,  structure,  and  decisiveness  in  public, 
and  keep  their  data  gathering  internal. 
Perceivers  tend  to  prefer  openness,  flexi¬ 
bility,  and  adaptability — and  keep  their 
decisions  internal.  At  a  systems  level,  dais 
is  often  reflected  in  how  project  teams 
manage  changing  requirements  and  the 
systems  development  process  itself.  Teams 
that  emphasize  Judging  tend  to  work  to 
minimize  uncertainty,  often  attempting  to 
lock  in  requirements  early,  consistent  with 
a  Waterfall  development  world  view. 
Teams  that  emphasize  Perceiving  tend  to 
take  a  more  emergent  adaptive  approach 
to  development,  evolving  designs  based  on 
the  learning  done  over  time. 

The  best  systems  development  ap¬ 
proaches  blend  closure  and  adaptation, 
characteristics  of  Judging  and  Perceiving. 
Examining  the  processes  followed  in  well- 
constructed  iterative,  adaptive,  and  Spiral 
software  development  methodologies 
reveal  this  balance.  These  processes  reflect 
fluidity  in  moving  between  activities  that 
gather  information  (eliciting  requirements, 
storyboarding),  focus  on  decisions  (deliv¬ 
erables  sign-off,  product  releases),  and 
those  that  blend  tire  two  (prototyping  to 
both  expose  new  needs  and  determine 
desired  directions;  testing  to  both  expose 
bugs  and  resolve  them). 

At  the  individual  level,  the  goal  is  to 


22  CROSSTALK  The  Journal  of  Defense  Software  Engineering 


May /June  2010 


Optimizing  Myers-Briggs  Type  Indicator  Training:  Practical  Applications 


The  Psychological  Type  Model 
Preference  Pairs 


Extraversion 

Gains  energy  from  an  outer  world 
of  people,  action,  and  things. 

. .  Extraversion  and  Introversion  . . 

Energy  Source 

Introversion 

Gains  energy  from  an  inner  world 
of  concepts  and  ideas. 

Sensing 

First  perceives  the  immediate,  practical, 
real  facts  of  experience.  Collects 
here-and-now  sensory  information. 

Sensing  and  Intuition 

Data  Gathering 

Intuition 

First  perceives  possibilities,  patterns 
and  meanings,  and  of  experience. 
Collects  information  through  impressions. 

Thinking 

Objective  decision-making.  Seeks  clarity 
by  detaching  themselves  from  problem; 
cause-effect  oriented. 

Thinking  and  Feeling 

Decision-Making 

Feeling 

Subjective  decision-making.  Seeks 
harmony  with  inner  values  by  placing 
themselves  within  problem. 

Judging 

Prefers  to  live  in  a  decisive,  planned 
way,  with  the  goal  of  reaching  closure  in 
the  external  world. 

_  Judging  and  Perceiving  _ 

Outer-World  Orientation 

Perceiving 

Prefers  to  live  in  a  spontaneous,  flexible 
way,  preferring  to  stay  open  to  new 
information  in  the  external  world. 

Figure  1 :  MBTI  Assessment  Preference  Scales  [1] 


identify  preferences  to  arrive  at  one’s  four* 
letter  personality  type:  ESTJ  for 
Extraversion,  Sensing,  Thinking,  Judg¬ 
ment  and  INFP  for  Introversion,  In¬ 
tuition,  Feeling,  Perception.  A  personality 
type  is  made  up  of  the  four  letters  that 
reflect  the  aggregation  of  a  person’s  pref¬ 
erences  on  each  scale:  For  example,  I  pre¬ 
fer  Introversion  (I),  Intuition  (N),  Feeling 
(F),  and  Judging  (J),  so  my  type  is  INFJ. 
Understanding  my  type  allows  me  to  bet¬ 
ter  manage  my  personal  strengths  and 
blind  spots,  on  a  project  or  in  any  other 
environment.  At  the  project  level,  the  goal 
is  to  balance  all  the  preferences  and  their 
contributions  across  the  project;  this  is 
because  in  the  end,  each  of  the  eight  pref¬ 
erences  provides  a  benefit  to  a  project.  By 
learning  to  balance  each  pair  of  prefer¬ 
ences,  we  can  realize  the  contribution  of 
each  and  mitigate  the  risk  of  over-empha¬ 
sizing  one  at  the  expense  of  die  other. 

Table  1  summarizes  the  patterns  I  have 
seen  on  projects  over  the  course  of  the 
past  decade,  where  the  overemphasis  of 
one  preference  at  the  detriment  of  the 
other  has  translated  into  concrete  risks  on 
real  projects.  More  examples  of  these  are 
covered  in  both  [2]  and  [3] . 

Type  as  a  Problem  Solving 
and  Decision-Making  Model 

Much  of  what  leaders  and  teams  do  each 
day,  including  the  tasks  that  support  sys¬ 
tems  development,  consist  of  two  prima¬ 
ry  activities:  taking  in  information  and 
making  decisions  based  on  that  data.  As 
such,  data  gathering  and  decision-making 
are  key  components  of  planning  and 
problem  solving. 

The  second  and  third  scales  of  the 
psychological  type  model,  Sensing  and 
Intuition  and  Thinking  and  Feeling,  were 
identified  as  the  mental  functions  by  Carl 
Jung.  Sensing  and  Intuition  are  the  prefer¬ 
ences  that  make  up  the  perceiving  func¬ 
tion,  or  how  we  prefer  to  gather  informa¬ 
tion.  Thinking  and  Feeling  are  the  prefer¬ 
ences  that  make  up  the  judging  function, 
or  how  we  prefer  to  make  decisions. 
Together,  these  four  preferences  create  a 
practical  and  easy-to-apply  decision-mak¬ 
ing  and  problem  solving  model. 

Table  2  (see  the  following  page)  repre¬ 
sents  the  components  of  an  all-function 
model  for  problem  solving  and  decision¬ 
making.  There  are  three  steps  to  using  this 
model: 

1.  Explicitly  state  the  specific  problem 
being  faced,  need  to  be  filled,  or  the 
decision  to  be  made.  This  can  be  hard¬ 
er  than  it  sounds.  Sensing  groups  tend 
to  dive  into  the  history  and  the  details, 


and  must  integrate  these  into  a  single 
statement  that  captures  the  building 
blocks.  Intuitive  groups  tend  to  see 
everything  as  related,  and  must  work 
to  develop  a  statement  that  is  concrete 
and  specific  enough  to  work  with  in  a 
meaningful  way. 

2.  Next,  for  that  need  or  problem  state¬ 
ment  or  decision  to  be  made,  ask  the 
questions  in  Table  2.  Most  teams  find 
it  helpful  to  work  through  the  ques¬ 
tions  in  order.  Block  die  time  so  that 
the  group  reserves  an  even  amount  of 
time  for  each  of  the  four  preferences. 

3.  Finally,  identify  the  decisions,  action 
items,  and  next  steps  that  are  suggest¬ 
ed  by  the  discussion,  and  craft  a  plan 
for  implementing  and  communicating 
these. 

I  have  seen  groups  effectively  self- facil¬ 
itate  this  process  in  a  one-  to  two-hour 


meeting.  With  some  focus,  these  groups 
start  to  solve  problems  and  make  decisions 
that  can  have  a  genuine  impact  on  project 
success.  Through  this  process,  the  team 
also  generally  discovers  which  of  the  pref¬ 
erences  come  more  easily  to  die  group. 
Answering  the  questions  linked  to  prefer¬ 
ences  that  are  on  the  radar  will  generally 
yield  more  familiar  conversations  (i.e.,  the 
content  will  likely  already  be  on  the  group’s 
view  screen).  For  the  preferences  that 
come  less  easily  to  the  group,  the  questions 
are  likely  to  reveal  new  and  fresh  informa¬ 
tion  that  has  not  yet  been  previously  con¬ 
sidered.  This  is  content  that  may  have  pre¬ 
viously  fallen  under  die  radar;  the  associat¬ 
ed  type  preference,  therefore,  might  bene¬ 
fit  from  some  additional  attention. 

Type  and  Project  Planning 

This  same  all-function  model  can  be 


Table  1:  Preferences  Out  of  Balance  Lead  to  Risks 


MBTI  Preference 

Result  of  Overemphasis 

Extraversion 

Scope  creep,  if  too  much  discussion  leads  to  more  action  items,  and 
possibilities  spoken  aloud  are  interpreted  as  directions  and  decisions. 

Introversion 

A  lack  of  scope  clarity  and  alignment,  if  people  assume  that  others  know 
the  decisions  and  direction  when  (in  fact)  they  do  not. 

Sensing 

More  time  tracking  than  doing,  if  the  team  focuses  too  heavily  on  the 
granularity  and  specifics  of  schedule  and  task  elements. 

Intuition 

Slipping  timelines,  if  the  concrete  realities  of  task  performance  take 
longer  than  the  big-picture  visioning  anticipated. 

Thinking 

Lack  of  user  involvement  and  stakeholder  buy-in,  if  technology-focused 
specifications  overcome  people-oriented  interests. 

Feeling 

Lack  of  tough  trade-offs  and  risk  management,  if  the  team  works  to 
keep  all  stakeholders  happy  and  avoid  necessary  constructive  conflict. 

Judging 

Project  completion  without  project  success,  if  the  drive  for  closure 
overcomes  the  benefits  of  needed  discoveries  along  the  way. 

Perceiving 

Interim  success  without  actual  completion,  if  the  pursuit  of  options  leads 
to  exhaustion  of  time  and  budget  without  a  final  product. 
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Preference 

Effective  Questions: 

“In  Making  This  Decision  or  Solving  This  Problem  ...” 

Sensing 

•  What  is  the  current  situation,  as  it  is?  What  facts  and  details  describe 
where  we  are? 

•  What  past  experience  can  we  learn  from? 

•  What  are  the  important  details  on  which  to  focus? 

•  What  should  we  keep  that  works? 

Intuition 

•  What  are  the  patterns  or  themes  across  the  details  and  past  experience? 

•  What  is  the  big-picture  view?  What  is  the  vision  we  want  to  achieve? 

•  Are  there  relevant  models  or  concepts  to  help  frame  the  issue? 

•  What  are  the  possibilities  or  options?  What  could  we  do? 

Thinking 

•  What  are  the  criteria  that  will  determine  the  best  approach?  How  will 
we  decide? 

•  What  are  our  best  alternatives  with  their  respective  pros  and  cons? 

•  What  are  the  most  logical  solutions? 

•  How  will  we  objectively  assess  success? 

Feeling 

•  With  whom  do  we  need  to  collaborate  and  in  what  ways? 

•  How  will  the  proposed  options  and  goals  impact  the  various  people 
involved  or  impacted  in  the  situation? 

•  Which  approaches  will  promote  maximum  acceptance  and  ownership? 

•  How  will  we  communicate  our  plan  to  others? 

Table  2:  All-Function  Problem-Solving  and  Decision-Making  Model  [1] 


applied  to  project  planning.  It  is  widely 
accepted  that  project  planning  done  well 
can  save  time  later,  particularly  when  it  is 
done  with  an  eye  to  how  uncertainty  and 
change  will  be  handled  downstream. 
Given  the  importance  of  project  planning, 
it  is  an  attractive  activity  to  consider 
through  the  lens  of  psychological  type. 

From  a  psychological  type  perspective, 
early  planning — because  it  is  by  definition 
future  focused — is  often  positioned  under 


the  Intuition  preference,  with  common 
references  to  visioning  and  thinking  outside 
the  box.  Later,  when  work  breakdown 
structures  are  underway,  the  more  present 
and  detail-focused  Sensing  preference  may 
take  center  stage.  When  balanced  well,  all 
four  preferences  support  effective  plan¬ 
ning: 

•  Sensing:  Provides  experience-based 
data  and  best  practices  that  can  help 
bridge  the  present  to  future  vision. 


•  Intuition:  Provides  future  possibili¬ 
ties,  patterns,  and  conceptual  models 
for  the  future. 

•  Thinking:  Provides  objective  evalua¬ 
tion  criteria  for  decisions  and  trade-off 
analysis. 

•  Feeling:  Considers  how  directions 
and  decisions  will  be  perceived  by  and 
impact  different  groups  and  people. 
Table  3  summarizes  what  project  plans 

can  struggle  with  when  the  Perceiving  and 
Judging  preferences  are  out  of  balance, 
and  some  steps  that  can  be  taken  to  re-bal- 
ance  each  pair. 

Balancing  Preference  Pairs  at 
the  Project  Level 

The  discussion  now  turns  to  the  imple¬ 
mentation  and  communication  phases, 
and  how  to  balance  issues  like  Extraver¬ 
sion  and  Introversion,  as  well  as  Perceiv¬ 
ing  and  Judging,  at  the  project  level. 

For  example,  Extraversion  and 
Introversion  are  useful  in  understanding 
one’s  source  of  energy  at  the  individual 
level.  At  the  project  level,  the  preference 
pair  can  be  useful  for  determining  and 
monitoring  stakeholder  and  team  involve¬ 
ment  and  communication. 

Projects  that  are  out  of  balance 
towards  Extraversion  (too  much  external 
focus)  can  struggle  from  an  over-involve¬ 
ment  of  stakeholders,  leading  to  difficul¬ 
ties  with  expectations  management  and  in 
keeping  sensitive  or  incomplete  ideas 
from  being  widely  released.  Projects  that 
are  out  of  balance  towards  Introversion 
(too  much  internal  focus)  can  struggle 
with  a  lack  of  communication,  and  may  fly 
so  far  under  the  radar  that  they  lose  upper 
leadership  support. 

For  balancing  Extraversion  and 
Introversion,  ask  the  following  questions: 

•  Who  should  be  involved  in  what  kinds 
of  project  decisions  and  how  will  they 
be  engaged? 

•  What  is  the  needed  breadth  and  depth 
of  engagement  with  different  stake¬ 
holder  groups? 

•  How  will  we  communicate  and  main¬ 
tain  connections  with  team  members, 
senior  leaders,  and  customers? 

Judging  and  Perceiving — which  relate 

to  preferences  for  closure  and  openness — 
are  invaluable  tools  at  the  project  level  for 
balancing  both  attentiveness  to  meeting 
milestones  and  openness  to  opportunities 
and  contingencies. 

Projects  that  are  out  of  balance  with 
Judging  can  struggle  with  coming  to  clo¬ 
sure  too  early,  with  concerns  about  meet¬ 
ing  milestones  trumping  considerations  of 
new  information.  In  these  cases,  contin- 


Table  3:  Equalising  Unbalanced  Functions 


Action 

When  Either  Side  is  Overemphasized 

Ways  to 

Balance 

Data 

Sensing.  Plans  become 

Intuition.  Plans 

•  For  each  element  of  the  vision, 

Gathering 

an  overly  detailed 

become  too  abstract 

take  the  time  to  break  it  down  into 

compilation  of  people's 

to  be  useful,  miss 

the  concrete  action  and  steps  that 

anticipated  daily 

the  realities  that 

will  bring  that  element  to  fruition. 

activities,  and  are  too 

are  required  to  craft 

•  Once  the  details  are  in  place, 

specific  and  all- 

schedules  and 

regularly  recheck  to  affirm  alignment 

encompassing  to  reveal 

budgets,  and  are 

with  the  big  picture. 

the  big-picture  and 

not  grounded  in 

•  If  the  project  gets  too  in  the  weeds, 

general  decision-making 

concrete  data  to 

take  the  time  to  identify  root  causes, 

criteria. 

support  daily 
decision-making. 

patterns,  and  brainstorm  possibilities. 

•  If  the  project  gets  lost  in  theory,  work 
to  identify  specific  tactical  steps  that 
can  be  taken  immediately  to  head 
in  the  right  direction. 

Decision- 

Thinking.  Plans  leave  out 

Feeling.  Plans  omit 

•  Develop  objective  criteria  for 

Making 

the  customer’s 

the  decision  criteria 

alternative  analysis  and  trade-off 

perspective  and  fail  to 

and  performance 

decision-making. 

spend  adequate  time  on 

measures  that  will 

•  Assign  both  roles  and  specific 

change  management  and 

drive  tradeoff 

times  in  the  project  schedule  for 

communication. 

decisions  and 
objective  measures 
of  progress. 

stakeholder  and  customer  outreach. 

•  If  the  project  overemphasizes 
products  and  problems,  stop  and 
take  time  to  focus  on  how 
stakeholders  are  being  consulted 
and  included. 

•  If  the  project  is  overemphasizing 
people  concerns,  ask  what  needs  to 
be  done  to  refocus  on  objective 
decisions. 
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gency  planning  is  often  left  off  the  list,  as 
die  project  team  works  to  eliminate  uncer¬ 
tainty  rather  than  plan  for  it.  Projects  that 
are  out  of  balance  with  Perceiving  strug¬ 
gle  with  staying  open  too  long,  running 
out  of  time  and  resources  as  different 
alternatives  are  explored. 

For  balancing  Judging  and  Perceiving, 
ask  the  following  questions: 

•  What  milestones  will  be  set  as  check-in 
points,  and  how  will  these  check-ins 
occur? 

•  How  do  we  plan  to  be  flexible?  How 
will  we  know  when  a  goal  or  objective 
no  longer  makes  sense,  and  how  will 
we  regroup  when  that  happens? 

•  What  are  some  of  the  contingencies 
that  would  trigger  a  review  of  the  pro¬ 
ject  plan,  processes,  and  proposed 
products? 

Maximizing  the  Return  on 
Investment 

Once  they  learn  about  the  benefits  of 
applying  type  to  project  and  systems  man¬ 
agement,  many  managers  ask  whether 
tliey  should  be  selecting  team  members 
based  on  preferences.  It  is  tempting  to 
want  to  take  this  route;  however,  because 
it  evaluates  preferences — but  not  skills, 
knowledge,  or  abilities — the  MBTI  assess¬ 
ment  is  not  a  valid  tool  for  hiring,  team 
selection,  or  promotion. 

Instead,  managers  should  construct  a 
list  of  the  behaviors  and  experiences  that 
would  ideally  be  reflected  across  a  project 
team,  or  in  a  specific  role  that  needs  filling. 
The  ideas  explained  in  this  article  can  be 
used  to  inform  that  list  to  select  a  diverse 
set  of  people  for  the  team,  or  to  identify 
individuals  that  would  bring  behaviors, 
skills,  and  experiences  that  are  underrepre¬ 
sented.  For  example,  systematically  look¬ 
ing  across  the  preferences  may  highlight 
skills  that  are  needed,  but  that  may  not 
have  been  previously  valued.  The  goal  is 
to  recruit  a  group  of  people  that  can  deliv¬ 
er  on  those  skills,  regardless  of  their  actu¬ 
al  preferences. 

It  is  never  too  late  to  integrate  type  or 
the  MBTI  assessment  as  a  tool  in  project 
planning  or  execution.  For  example,  a 
mid-point  project  review  utilizing  the  all- 
function  problem  solving  model  may 
help  reveal  patterns  in  the  project’s  risks 
that  had  not  been  detected,  or  actions 
that  had  not  been  previously  considered 
to  correct  course.  It  can  even  be  used  at 
the  end  of  a  development  project  as  the 
mission  changes  from  development  to 
longer-term  operations  or  deployment. 
Wherever  the  project  might  be  in  its  life, 
reviewing  the  benefits  of  each  preference 


Software  Defense  Application 

This  article  strives  to  connect  relationship  management  with  software  development 
through  a  tool  that  many  in  the  DoD  are  familiar  with — but  have  not  yet  optimized  in 
project  delivery.  It  provides  concrete  examples  of  how  die  MBTI  can  be  applied  to  bet¬ 
ter  understand  common  software  development  challenges,  building  on  MBTI  knowl¬ 
edge  that  many  DoD  personnel  already  have,  but  are  not  yet  clear  on  how  to  apply. 


is  a  great  step  for  continuous  improve¬ 
ment.  Start  with  dais  exercise,  which  asks 
some  basic  questions: 

•  When  considering  all  eight  type  prefer¬ 
ences,  what  are  we  doing  well? 

•  What  are  we  not  doing  so  well? 

•  What  do  we  need  to  do  differently 

based  on  this? 

Often,  the  answers  will  point  to  opportu¬ 
nities  for  greater  balance  across  the  pref¬ 
erences,  to  both  maximize  strengths  and 
fill  holes. 

Systems  development  and  IT  profes¬ 
sionals  are  frequently  criticized  for  focus¬ 
ing  on  the  benefits  of  a  specific  software 
or  process  tool,  rather  than  focusing  on 
die  customer’s  functional  need  or  prob¬ 
lem.  Too  often,  professionals  marketing 
die  MBTI  assessment  do  die  same  thing: 
They  market  and  deploy  the  tool  without 
making  the  direct  link  to  a  problem  or 
need  that  the  customer  actually  has.  This 
results  in  fun  workshops  and  enhanced 
self-awareness  for  diose  who  connect  with 
die  tool,  but  may  not  be  the  optimal  out¬ 
come  for  the  system  as  a  whole,  given  the 
cultural  investment  in  the  MBTI  across 
die  DoD. 

The  reality  is  that  the  dieory  underly¬ 
ing  the  MBTI  is  a  remarkably  flexible  one, 
and  can  be  used  as  a  diagnostic  assessment 
and  intervention  tool  at  multiple  levels: 
individual,  team,  project,  and  organiza¬ 
tion.  Now  that  many  DoD  programs  and 
projects  have  experience  with  the  MBTI,  it 
is  time  to  take  the  next  step,  expanding  its 
application  to  more  deeply  understand 
and  address  all  die  thorny  challenges  of 
project  performance.  Doing  so  will  lead  to 
better  conversations,  better  teams,  and 
better  systems — one  program  at  a  time.4 
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The  Department  of  Homeland  Security,  Office  of  Cybersecurity 
and  Communications,  is  seeking  dynamic  individuals  to  fill  several 
positions  in  the  areas  of  software  assurance,  information 
technology,  network  engineering,  telecommunications,  electrical 
engineering,  program  management  and  analysis,  budget  and 
finance,  research  and  development,  and  public  affairs.  These 
positions  are  located  in  the  Washington,  D.C.  metropolitan  area. 

To  learn  more  about  DHS’  Office  of  Cybersecurity  and 
Communications  and  to  find  out  how  to  apply  for  a 
position,  please  visit  USAJOBS  at  www.usajobs.gov. 


The  20 1 0  Software  Best  Practices 
Webinar  Series 

www.itmpi.org/webinars 

The  IT  Metrics  and  Productivity  Institute  sponsors  a  series 
of  Webinars  dedicated  to  improving  the  practice  and  man¬ 
agement  of  software  development  and  maintenance  world¬ 
wide.  All  live  Webinars  are  free,  have  been  accredited  by  the 
Project  Management  Institute,  and  earn  participants  profes¬ 
sional  development  units.  Each  features  an  expert  speaker 
who  has  extensively  researched  and  successfully  applied  best 
practice  principles  to  the  development  and  maintenance  of 
software.  CROSSTALK  mainstay  Capers  Jones — along  with 
other  past  authors  Christof  Ebert,  Donald  J.  Reifer,  Herb 
Krasner,  Ian  Brown,  Robert  Charette,  David  Herron,  Dan 
Galorath,  Arlene  Minkiewicz,  David  Garmus,  and  Neil 
Potter — are  scheduled  to  hold  Webinars  this  year. 

DoD  Acquisition  Workforce  Career 
Management 

www.dau.mil/workforce 

After  reading  Influencing  Software  Competencies  Across  the 
DoD  Acquisition  Workforce,  why  not  go  to  the  Web  site 
focused  on  that  group?  You  can  read  about  the  Defense 
Acquisition  Workforce  Improvement  Act  and  its  latest 
changes,  view  a  detailed  catalog  of  the  DAU’s  classroom  and 
online  learning  opportunities,  and  learn  about  what  specif¬ 


ic  entities  (Army,  Navy,  Air  Force,  and  civilian  employee 
services)  are  doing  in  regards  to  acquisition  workforce  sup¬ 
port.  Also  available  are  the  latest  memos  from  DoD  leader¬ 
ship  regarding  strategic  goals,  education,  career  advance¬ 
ment,  and  certification  strategies. 

How  Did  the  Originators  of  the  Agile 
Manifesto  Turn  from  Technology 
Leaders  to  Leaders  of  a  Cultural 
Change? 

www.infoq.com/articles/manifesto-originators 
If  you  liked  Dr.  Orit  Hazzan  and  Dr.  Tali  Seger’s  article  on 
self-efficacy  in  software,  CROSSTALK  recommends  their 
InfoQueue  exploration  of  the  Agile  Manifesto — and  its  cre¬ 
ators.  This  time  with  co-author  Gil  Luria,  Hazzan  and  Seger 
share  in-depth  interviews  with  12  of  the  17  originators  of 
the  Agile  Manifesto,  searching  for  influences  and  exploring 
how  technology-driven  forces  led  to  the  cultural  change 
introduced  by  the  Agile  approach.  Interviews  with  the 
framers  go  back  as  far  as  childhood  in  search  of  influences, 
explore  their  early  professional  lives  in  technology  and  soft¬ 
ware,  gain  differing  perspectives  from  that  famed  February 
2001  meeting,  and  explore  how  their  professional  roles  have 
changed  in  the  nine  years  since. 
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Human  Asset  Management 

Martin  Allen 

Independent  Software  Consultant 

Widely  recognised  as  the  “father  of  modern  economics,”  Adam  Smiths  seminal  hook,  “The  Wealth  of  Nations,”  included 
both  tangible  assets  (machines,  buildings,  and  land)  and  humans  as  essential  wealth-generating  resources.  Our  present  high- 
technology  industries  are  eager  to  invest  in  and  protect  their  tangible  assets  (such  as  computer  networks),  but  the  modern 
accountancy  paradigm  forces  the  view  of  an  etnployee  as  merely  a  cost.  Humans  are  indeed  primary  assets,  and  this  article 
provides  guidance  in  assessing,  utilising,  and  enhancing  their  value. 


Adam  Smith  was  both  influential  and 
controversial  in  his  inclusion  of 
humans,  or  labor,  as  a  major  contribution 
to  the  wealth  of  a  nation.  Then  again, 
Smith  was  not  the  only  visionary  in  18th 
century  Scotland  to  acknowledge  the 
human  contribution  to  business  and  eco¬ 
nomics.  With  the  Industrial  Revolution  in 
full  flow,  the  common  worker  was  per¬ 
ceived  by  industrialists  as  a  replaceable  cog 
in  a  machine,  there  to  turn  a  profit  and  to 
be  exploited.  Cotton  mill  owner  and  social 
reformer  Robert  Owen  would  break  that 
mold.  On  the  banks  of  the  River  Clyde 
(near  Glasgow)  stands  the  one-time  cot¬ 
ton  mill  town  of  New  Lanark  [1],  As  tes¬ 
timony  to  its  achievements,  the  mill  oper¬ 
ated  from  1786  until  1968  and  is  now  pre¬ 
served  as  a  World  Heritage  site.  What  dis¬ 
tinguished  the  mill-owner  from  others  at 
that  time  was  the  manner  in  which  he  nur¬ 
tured  the  workforce:  Having  decent 
homes  for  workers,  schools  for  their  chil¬ 
dren,  and  cooperative  shops  delivering 
goods  at  a  reasonable  value  contributed  to 
the  town’s  financial  and  communal  suc¬ 
cess.  For  Owen,  this  was  not  philanthropy; 
it  was  the  self-interest  of  capitalism, 
spiked  with  a  social  conscience.  As  clearly 
as  the  River  Clyde  was  needed  to  turn  the 
wheels  of  the  mill  machines,  Owen  recog¬ 
nized  that  people  were  needed  to  work  the 
looms  that  weave  the  cloth.  The  end-result 
was  employees  who  worked  harder  and 
better — and  created  a  higher-quality  final 
product. 

Human  Assets 

Adam  Smith  and  I  share  more  than 
nationality;  we  both  believe  that  humans 
are  key  assets  in  the  pursuit  of  economi¬ 
cally  favorable  results.  For  more  years  than 
I  care  to  admit  to,  I  have  held  a  strong 
conviction  that  substantial  and  sustainable 
advances  in  industrial-scale  software  engi¬ 
neering  will  not  come  from  new  tools  or 
programming  languages;  they  will  not 
emerge  from  the  hyperbole  surrounding 
heavyweight  or  lightweight  processes;  they 
will  not  come  from  accruing  quality 


badges  or  collecting  metrics;  and  they  will 
not  arrive  via  a  modeling  notation  (such  as 
the  Unified  Modeling  Language).  The 
potential  for  improvement  is  the  most  that 
various  software  tools,  techniques,  and  ini¬ 
tiatives  can  ever  deliver.  Substantive 
progress  has  been — and  will  continue  to 
be — a  direct  consequence  of  employing 
software  professionals  and  providing 
them  with  a  suitable  environment  in 
which  to  operate.  Competent  personnel 
are  an  organization’s  pivotal  assets. 

people  aspects 
seem  to  dominate  the 
most  expensive  project 
disasters ” 

Having  an  appropriately  trained  soft¬ 
ware  workforce  has  a  double-edged  effect. 
Educated  teams  focus  on  productive 
work;  shared  knowledge  and  experience 
give  them  the  cohesion  with  which  to 
address  tire  intellectual  tasks  that  comprise 
engineering.  Equally  significant  is  that 
teams  spend  less  time  evaluating  and  cor¬ 
recting  substandard  software  artifacts  sim¬ 
ply  because  these  are  produced  in  negligi¬ 
ble  quantities  by  competent  engineers. 

While  there  is  a  widespread  fallacy 
that  technical  issues  are  the  primary 
source  of  project  woes,  people  aspects 
seem  to  dominate  the  most  expensive 
project  disasters.  Without  a  doubt,  the 
majority  of  perceived  difficulties  are  sim¬ 
ply  symptomatic  of  intrinsic  people  fac¬ 
tors  (politics  is  a  popular  euphemism  for 
these).  To  quote  from  the  influential 
book,  “Peopleware”: 

For  the  overwhelming  majority  of 
the  bankrupt  projects  we  studied, 
there  was  not  a  single  technological 
issue  to  explain  the  failure  ...  The 
major  problems  of  our  work  are 


not  so  much  technological  as  soci¬ 
ological  in  nature.  [2] 

Particularly  in  knowledge  economies, 
the  success  or  failure  of  technology  pro¬ 
grams  hinges  on  assessing  capabilities  and 
recognizing  the  needs  of  the  engineering 
teams.  To  this  end,  I  have  generated  seven 
human-centric  rules  for  software  develop¬ 
ment  organizations  to  adhere  to: 

•  Rule  1:  The  main  causal  factors  of 
project  success,  mediocrity,  or  failure 
should  be  recognized  as  human  and 
organizational,  not  technological. 

•  Rule  2:  Professionalism  and  software 
engineering  competence  should  be 
assessed  objectively  and  encouraged 
proactively  by  senior  management. 

•  Rule  3:  The  number  and  seniority  of 
software  professionals  employed  with¬ 
in  an  organization  should  be  commen¬ 
surate  with  the  magnitude  and  critical¬ 
ity  of  tire  required  software  systems. 

•  Rule  4:  Organizations  should  provide 
an  environment  conducive  to  the  intel¬ 
lectual  task. 

•  Rule  5:  Management  should  recognize 
its  primary  functions  are  to  attract, 
motivate,  facilitate,  and  retain  talent. 
Teams  should  be  given  an  identity,  a 
vision,  and  quality  goals. 

•  Rule  6:  Teams  should  be  organized 
with  respect  to  member  strengths  and 
competencies. 

•  Rule  7:  Dependable  sources  of  knowl¬ 
edge  should  be  provided  in  the  form  of 
textbooks  and  training  materials. 
Readers  familiar  with  my  May/June 

2009  Crosstalk  article  will  recognize 
two  of  these  rules.  Attention  was  also 
drawn  to  three  essential  ingredients  of 
software  development  called  die  3Ps:  peo¬ 
ple,  products,  and  processes  [3]. 

Human  Asset  Evaluation 

Not  all  assets  are  of  equal  value;  so  too 
can  be  said  of  human  assets.  The  process 
of  evaluation  for  most  assets  is  based  fun¬ 
damentally  on  attributes  and  objective  cri¬ 
teria,  with  a  variable  dash  of  subjectivity 
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on  top.  Houses  with  identical  specifica¬ 
tions  and  locations  (objective)  can  have 
different  valuations  due  to  the  varying 
attraction  of  the  decor  (subjective). 
Likewise,  diamonds  of  the  same  number 
of  carats  (objective)  can  have  different 
valuations  due  to  their  luster  (subjective). 
When  assessing  the  value  of  human 
assets,  we  can  follow  a  similar  scheme. 

The  main  objective  criteria  for  evaluat¬ 
ing  professional  (software)  engineers  are: 

•  Qualifications/education. 

•  Formal  training. 

•  Experience. 

If  necessary,  qualifiers  can  be  used  to 
turn  these  into  quantitative  criteria — con¬ 
sider  the  applicability,  duration,  and  timeli¬ 
ness  of  each  criterion.  For  example,  a  rele¬ 
vant  degree  is  very  valuable;  if  my  experi¬ 
ence  is  typical,  this  has  shaped  an  engineer’s 
aptitude  from  an  early  age. 

Subjective  criteria,  sometimes  referred 
to  as  soft  skills,  may  include: 

•  Communication  ability. 

•  Attitude /commitment. 

•  Adaptability. 

•  Assertiveness. 

Decent  soft  skills  are  particularly  relevant 
where  team  interaction  and  influence  are 
important. 

One  may  expect  the  formality  of  an 
employee  evaluation  scheme  to  vary  with 
respect  to  the  industry  and  the  criticality  of 
the  application.  With  safety-related  soft¬ 
ware  systems  in  Europe,  the  range  of  indi¬ 
vidual  and  team  competence  is  unaccept¬ 
ably  wide.  In  recent  years,  I  have  had  the 
pleasure  of  working  alongside  competent 
professionals  with  the  requisite  qualifica¬ 
tions,  training,  and  experience.  I  have  also 
worked  in  critical  environments  where, 


clearly,  the  engineers  lacked  even  basic 
skills.  Some  years  ago,  I  was  involved  in  an 
initiative  to  introduce  a  competence  assess¬ 
ment  scheme  into  a  safety-related  industry 
sector.  A  significant  number  of  managers 
and  engineers  were  unwilling  to  take  part  in 
the  scheme  until  the  objective  criteria  had 
been  replaced  by  subjective  criteria.  Those 
same  people  would  probably  balk  at  the 
idea  of  being  passengers  on  an  airplane 
flown  by  a  pilot  who  was  not  trained,  but 
who  had  a  pleasant  voice  over  the  speaker. 
Unfortunate  as  it  seems,  adopting  formal 
employee  evaluation  or  competence  assess¬ 
ment  schemes  is  like  diet  and  exercise — we 
need  it  to  stay  fit  and  healthy,  but  doing  the 
things  that  are  best  for  us  is  not  always  easy. 
For  safety-related  systems,  the  British 
Health  and  Safety  Executive  has  published 
guidelines  for  introducing  a  competence 
management  system  [4]. 

Could  the  certification  of  software 
engineering  professionals  be  the  answer  (or 
part  of  the  answer)  in  establishing  compe¬ 
tence?  As  is  often  the  case  when  challenged 
to  answer  a  software  engineering  question, 
we  rely  on  respected  sources  of  knowledge 
such  as  CROSSTALK.  Perhaps,  surprising¬ 
ly,  there  is  a  lack  of  information  on  profes¬ 
sional  certification;  the  obvious  conclusion 
is  that  certification  is  at  least  an  unpopular 
subject,  or  even  taboo.  Without  a  doubt, 
there  are  leading  academics  and  practicing 
professionals  who  are  concerned  about  the 
efficacy  of  certification  programs.  The 
core  of  the  IEEE’s  Certified  Software 
Development  Associate  and  Professional 
efforts  [5],  the  Software  Engineering  Body 
of  Knowledge,  has  been  criticized;  for 
example,  its  ability  to  encompass  all  appli¬ 
cation  domains  is  questionable.  However, 


my  own  experiences  (in  various  industry 
sectors  in  Europe)  show  a  multitude  of 
people,  particularly  in  technical  leadership 
roles,  who  would  be  fearful  of  successful 
certification  initiatives  that  could  expose 
their  shallow  grasp  of  a  deep  discipline. 

Perhaps  there  are  less  formal  and  more 
palatable  ways  of  assessing  an  engineer’s 
competence.  For  instance,  I  have  assem¬ 
bled  a  portfolio  from  the  many  projects  I 
have  worked  on.  This  collection  includes 
samples  of  requirements  specifications, 
architectural  designs,  test  specifications, 
process  definitions,  presentations,  lists  of 
technical  books  read  and  owned,  etc.  This 
gives  me  the  ability  to  show  someone  the 
level  of  my  experience  and  ability;  yet,  hav¬ 
ing  a  portfolio  is  far  from  common  in  our 
industries  and  it  receives  very  mixed  reac¬ 
tions.  As  DeMarco  and  Lister  suggest,  “It 
would  be  ludicrous  to  think  of  hiring  a  jug¬ 
gler  without  first  seeing  him  perform”  [2], 

On  the  topic  of  hiring  competent  staff, 
professionals  must  be  dismayed  at  the  high 
proportion  of  job  advertisements,  over  a 
substantial  period,  focused  on  low-caliber 
skills.  For  instance,  experiences  with  a  spe¬ 
cific  programming  language  or  a  particular 
requirements  management  or  design  tool 
are  often  cited  as  essential  skills.  With 
regard  to  requirements,  the  major  skill  is 
always  in  the  specification:  Tool  proficien¬ 
cy  can  inject  quality  into  requirements 
management,  not  the  specification  thereof. 
A  skilled  engineer  will  be  trained  to  specify 
atomic,  consistent,  structured,  and  testable 
requirements;  Wilson  provides  a  synopsis 
on  requirements  specification  in  [6]. 
Similarly  with  design  tools,  and  to  quote 
Grady  Booch,  “CASE  [Computer  Assisted 
Software  Engineering]  tools  have  allowed 
merely  bad  designers  to  produce  bad 
designs  more  quickly”  [7],  The  absolute  fix¬ 
ation  by  whole  industry  sectors  on  pro¬ 
gramming  language  experience  is  a  contin¬ 
uing  embarrassment.  There  is  an  ever-pre¬ 
sent  concern  in  our  profession  that  the 
wrong  categories  of  skills  are  encouraged 
and  valued. 

Judging  from  the  feedback  I  received 
from  my  previous  article,  the  most  con¬ 
tentious  areas  were  the  rules  and  the  sec¬ 
tion  dealing  with  people — specifically,  the 
contrasting  behavior  between  profession¬ 
als  and  amateurs.  For  a  comparison,  see 
Table  1. 

We  can  take  one  of  the  divergences 
between  these  groups  of  people  and  ana¬ 
lyze  it  further.  Consider  a  sliding  scale  with 
art  at  one  end  and  science  at  the  other.  If, 
by  a  process  of  task  analysis,  we  conclude 
that  the  creative  nature  of  software  engi¬ 
neering  and  its  resilience  to  practical  math¬ 
ematical  proof  places  it  nearer  art  than  sci- 


Table  1 :  Characteristics  of  Software  Professionals  versus  Amateurs 


The  Professional  Practitioner 

The  Amateur  or  Hobbyist 

Views  the  overall  task  as  an  engineering 
discipline. 

Describes  the  overall  task  as  an  art  or  craft. 

Promotes  a  holistic,  life-cycle  view. 

Holds  an  implementation,  coding  bias. 

Places  emphasis  on  the  application  or  problem 
domain,  and  presents  architectural  solutions. 

Places  emphasis  on  the  technical  detail  of 
the  solution  domain  to  the  detriment  of  the 
customer  or  user. 

Learns  principally  from  published  engineering 
literature. 

Learns  principally  by  emulating  colleagues. 

Encourages  compliance  with  industry 
standards. 

Prefers  improvised,  local  procedures. 

Employs  quality  criteria  to  manage  projects. 

Manages  projects  via  schedule  alone. 

Conveys  an  outward,  discipline  focus. 

Conveys  an  inward,  project  focus. 

Exhibits  a  balanced  approach  to  risk. 

Adopts  a  naive  approach  to  risk. 
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Software  Defense  Application 

Readers  will  benefit  from  this  defense  software  industry  insider’s  focus  on  the  proven, 
primary  influence  on  software  project  success  or  failure:  the  combined  capabilities  of 
development  team  members.  As  for  return  on  investment,  enhancing  team  capability 
is  unique  in  offering  potential  productivity  gain  factors  of  up  to  10  times.  Increasing 
team  capability  has  the  dual  effect  of  improving  the  quality  of  software  artifacts  and 
reducing  waste. 


ence,  we  must  pause  for  thought.  Good  lit¬ 
erature  is  founded  on  die  discipline  of 
strict  linguistic  standards  (e.g.,  punctuation, 
spelling,  and  grammar),  whereas  music  is 
founded  on  structures  for  tone,  rhythm, 
and  notation.  History  has  proven,  there¬ 
fore,  that  discipline  has  released  creativity, 
not  stifled  it:  Discipline  is  as  elemental  to 
an  artist,  writer,  or  musician  as  it  is  to  an 
engineer. 

When  a  student  receives  a  classical  edu¬ 
cation  in  software  engineering,  this  indoc¬ 
trinates  a  view  of,  and  an  approach  to,  die 
discipline  that  is  not  just  different  from 
common  practices,  perceptions,  and 
mythology — it  is  diametrically  opposed. 
The  gap  between  professional  and  amateur 
is  not  a  gap,  it  is  a  chasm.  Therefore,  in 
comparative  arithmetic  terms,  it  is  ludi¬ 
crous  to  assume  that  10  untrained  person¬ 
nel  can  perform  even  die  work  of  a  solitary 
professional.  Perhaps  this  accounts  for  the 
10  to  1  productivity  ratio  recorded  as  long 
ago  as  1975  by  Frederick  P.  Brooks  in 
“The  Mythical  Man-Month”  [8], 

In  1980, 1  was  a  new  graduate  working 
in  the  British  defense  industry.  I  was 
approached  by  a  concerned  manager  who 
observed,  “You  appear  to  be  faltering  and 
are  not  producing  code  as  quickly  as  your 
peers.”  No  one  amongst  this  large  office 
of  software  developers  had  ever  witnessed 
a  qualified  and  trained  softie  ratifying  and 
specifying  requirements,  devising  software 
architecture,  designing  the  software,  defin¬ 
ing  test  cases  and  recording  test  results,  as 
well  as  generating  robust  code.  Wind  the 
clock  forward  almost  three  decades  and,  in 
a  high-dependability  environment,  our 
team  was  tasked  to  review  multiple  soft¬ 
ware  requirements  specifications  pro¬ 
duced  by  untrained  personnel.  Even  with 
die  availability  of  practical  guidelines,  the 
authors  had  produced  worthless  specifica¬ 
tions.  Combined  with  the  worst  that  a  bot¬ 
tom-up,  functional  software  architecture 
has  to  offer,  the  project  was  in  an  undesir¬ 
able  state.  The  real  problem  in  such  a  sce¬ 
nario  is  that,  again,  a  group  of  untrained 
people  cannot  match  the  actual  productiv¬ 
ity  of  one  professional.  Equally,  the 
majority  will  dominate  proceedings  and  a 
solitary  professional  will  toil  to  correct  the 
substantial  but  substandard  output  of  10 
untrained  employees. 

Lean  Engineering  is  a  populist  topic, 
although  it  is  well-documented  that  pro¬ 
duction-oriented  techniques  do  not  trans¬ 
fer  readily  into  a  (software)  development 
environment — also  known  as  the  make  a 
cheeseburger,  sell  a  cheeseburger  mentality  dis¬ 
cussed  in  [2],  Nonetheless,  one  of  the 
principles  of  Lean  is  the  reduction  of 
waste  in  a  production  line.  In  terms  of 


waste,  having  non-professional  software 
personnel  producing  substandard  artifacts 
is  analogous  to  having  an  untrained  team 
preparing  and  then  selling  raw,  frozen 
burgers  on  a  bun,  with  or  without  the 
cheese.  In  order  to  rectify  this  and  similar 
waste  issues,  an  organization  may  choose 
to  assess  the  capabilities  and  training 
needs  of  project  personnel — or  choose  to 
assess  the  competence  of  the  manage¬ 
ment  team  that  appointed  and  tasked 
untrained  personnel  in  die  first  instance. 

If  the  economic  aspects  of  the  soft¬ 
ware  engineering  life  cycle  were  ever  to  be 
modeled,  the  most  significant  variables  in 
die  equation  would  reflect  the  human 
knowledge  and  experience.  Then  again, 
die  life  cycle  has  been  modeled  and  the 
people  capability  attributes  are  die  most 
significant.  Barry  Boehm  identified  this 
truism  as  early  as  the  1 980s,  and  it  is  cap¬ 
tured  in  COCOMO  [9], 

There  are  already  significant  clues  here 
as  to  how  to  assess  die  value  or  compe¬ 
tence  of  software  engineering  personnel. 
However,  if  your  organization  is  still 
searching  for  a  magical  productivity 
enhancer,  then  look  to  laetrile1  for  the 
futility  of  searching  for  wonder  cures,  or 
“easy  technological  non-solutions”  as 
described  fully  in  chapter  6  of  [2]  and 
again  in  Brooks’  “No  Silver  Bullet”  chap¬ 
ter  in  [8], 

Human  Asset  Enhancement 

As  we  know,  many  assets  (like  cars)  depre¬ 
ciate  in  value,  while  others  (like  real  estate) 
increase  in  value — so  we  maintain,  build 
on,  and  insure  against  loss  those  appreci¬ 
ating  investments.  Humans  increase  in 
worth  through  enhanced  knowledge  or 
experience  and,  likewise,  an  organization 
is  prudent  to  invest  time  and  money  on  its 
most  precious  people  assets  as  well  as  to 
guard  against  the  mishap  of  their  loss.  In 
our  competitive  technology-driven  mar¬ 
kets,  companies  striving  to  be  die  best 
have  to  attract,  nurture,  and  retain  high- 
caliber  engineers. 

I  remember  an  organization  that  pur¬ 
chased  each  member  of  its  administrative 
personnel  a  top-of-the-line  PC  and  smart 
laser  printer.  What  happened?  The  engi¬ 
neers  stopped  squabbling  over  their  rent¬ 


ed,  one-between-five,  basic  machines — 
and  looked  on  enviously.  In  this  case,  the 
organization  showed  a  blatant  disregard 
for  its  engineers.  After  this,  many  resumes 
were  typed  into  those  rented  computers, 
including  my  own.  When  an  organization 
equips  all  of  its  people  adequately,  pro¬ 
vides  an  environment  conducive  to  the 
intellectual  task  of  technological  develop¬ 
ment,  and  supports  personnel  growth,  it 
in  turn  maintains,  enhances,  and  protects 
human  asset  value.  Engineers  are  people, 
and  people  need  to  feel  their  contributions 
are  valued. 

As  indicated  earlier,  staff  competence 
assessment  schemes  are  often  viewed  neg¬ 
atively — but  suppose  such  assessments 
were  shown  to  link  directly  to  an  organi¬ 
zation’s  development  of,  and  investment 
in,  its  people.  Therefore,  the  most  effec¬ 
tive  teams  can  be  organized  on  the  objec¬ 
tive  basis  of  competence  rather  than  on 
arbitrary  and  subjective  opinions.  As  initial 
reluctance  gives  way  to  synergy,  people 
will  gel  into  strong  teams. 

Having  assembled  a  strong  team  of 
competent  professionals,  how  should  it  be 
organized?  Brooks  gives  sound  advice  in 
his  “The  Surgical  Team”  [8]  chapter.  A 
surgeon  and  his  surgical  assistant  perform 
an  operation,  while  supported  by  nurses, 
an  anesthesiologist,  and  administrative 
staff.  This  arrangement  compares  favor¬ 
ably  with  the  roles  of  software  architect, 
software  manager,  programmers,  testers, 
and  an  administrator2.  Consider  the  differ¬ 
ence  in  the  structure  and  formalism  with¬ 
in  different  groups  of  musicians.  A  ran¬ 
dom  collection  of  musicians  can  meet  for 
a  jam  session;  without  proper  direction  or 
sheet  music,  the  small  group  can  still  pro¬ 
duce  some  decent,  improvised  sounds. 
Similarly,  a  small  band  of  jazz  musicians 
can,  given  reasonable  levels  of  compe¬ 
tence  and  practice,  entertain  an  apprecia¬ 
tive  audience.  However,  to  reach  the  excel¬ 
lence  of  a  large  professional  orchestra  is  a 
monumental  challenge  in  systematic  coor¬ 
dination — die  conductor  on  the  rostrum 
and  the  sheet  music  are  not  just  for  show. 
For  technical  teams  developing  software¬ 
intensive  systems  of  systems,  the  analogy 
is  clear:  Systematic  and  formal  coordina¬ 
tion  is  essential. 
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Having  assembled  a  strong  team  of 
competent  professionals,  how  should  it  be 
managed?  Consider  an  environment 
where  managers  (verbally)  whip  teams  to 
meet  implausible  milestones;  where  engi¬ 
neers  are  forced  to  cut  corners  and  under¬ 
mine  basic  quality  criteria;  where  training 
is  regarded  as  an  unnecessary  expense, 
and  reading  a  book  is  considered  a  waste 
of  company  time;  where  professional 
opinions  are  most  unwelcome  and  people 
are  expected  to  just  get  on  with  the  job; 
where  political  mendacity  is  a  substitute 
for  competence;  where  knowledge  is 
wielded  like  a  bludgeon  with  people  herd¬ 
ed  into  pens  like  cattle;  in  an  office  where 
it  is  too  hot,  cold,  or  noisy  for  anyone  to 
function  efficiently.  In  contrast,  imagine 
an  environment  where  people  are  encour¬ 
aged  to  design  outstanding  products; 
where  teams  and  individuals  are  chal¬ 
lenged  to  excel;  an  office  with  shelves 
groaning  from  the  weight  of  books  by 
software  gurus;  where  training  is  viewed  as 
a  necessity;  where  professionalism  is  a 
given;  where  diverse  opinions  are  seen  as 
die  balance  in  an  open  political  culture; 
where  personnel  are  provided  widi  ade¬ 
quate  tools  and  comfort;  and  a  place 
where  die  organization  and  staff  have 
mutual  goals  and  aspirations.  In  summary, 
it  is  as  easy  to  obtain  the  least  value  from 


your  human  assets  as  it  is  to  obtain  the 
most  value. 

Conclusion 

The  legacies  of  Adam  Smidi  and  Robert 
Owen  are  an  important  reminder  to  us  diat 
people  are  at  die  heart  of  commercial  and 
social  success.  In  our  rapidly  changing  tech¬ 
nological  world,  it  is  wordi  considering 
dieir  centuries-old  wisdom.  Perhaps  diere 
is  an  opportunity  for  our  organizations  to 
look  again  at  the  value,  radier  dian  the  cost, 
of  their  people  assets.  When  people  are 
viewed  truly  as  vital  assets,  dien  investment 
in  diem  is  sure  to  deliver  a  mutually  benefi¬ 
cial  corporate  future.  This  will,  in  turn,  lead 
to  greater  customer  satisfaction. ♦ 
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Notes 

1.  Laetrile  is  an  extract  from  apricot 
stones,  sold  in  Mexico  as  a  (fraudulent) 
cure  for  cancer. 

2.  The  role  of  software  manager  here  is 
one  of  a  facilitator,  rather  dian  a  tech¬ 
nical  lead.  Team  composition  should 
also  vary  widi  the  magnitude  and  criti¬ 
cality  of  die  task. 
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Grace  Murray  Hopper: 
We  Still  Need  You! 


During  my  15-plus  years  of  writing  BACKTALK  columns,  I 
have  often  found  myself  working  a  column  while  traveling. 
I  am  usually  in  one  of  three  conditions:  1)  bored,  stuck  in  my 
hotel,  not  much  to  watch  on  TV;  2)  bored,  on  yet  another  flight 
with  no  movie  and  a  bad  book  that  doesn’t  hold  my  attention;  or 
3)  frustrated  and  bored,  sitting  in  an  airport,  waiting  for  a  late 
flight. 

This  week,  I  had  the  pleasure  to  attend  the  SIGCSE — Special 
Interest  Group  on  Computer  Science  Education — in  Milwaukee. 
Great  conference,  but,  unfortunately,  on  my  way 
home,  the  third  condition  applied.  You  see,  I 
planned  this  conference  around  my  spring  break. 

Once  I  landed  in  Houston,  I  was  driving  to 
Orlando  with  my  family  to  visit  my  parents.  We 
were  leaving  as  soon  as  I  touched  down  in 
Houston,  so  I  was  in  a  hurry. 

The  weather  in  Milwaukee  has  been  mixed  all 
week,  so  I  watched  the  weather  closely — and  on 
this  morning  we  had  fog,  rain,  and  20  mph  winds. 

However,  the  airline  assured  me  that  the  incom¬ 
ing  and  outgoing  flights  were  on  time.  When  I 
got  to  the  airport,  my  departing  aircraft  was  15 
minutes  early — it  was  quickly  deplaned,  cleaned, 
the  old-for-new  luggage  exchanged,  and  the 
boarding  door  was  opened.  All  was  right  with  the 
world. 

One  problem:  There  was  no  flight  crew.  I 
found  out  that  while  the  plane  itself  had  come  in  from  decent 
Midwest  weather,  our  flight  crew  was  coming  in  from  Newark 
where,  apparently,  Noah  was  floating  down  the  main  runway, 
picking  up  small  animals  left  and  right. 

So  unfortunately,  while  all  the  “hardware”  was  ready,  some¬ 
thing  critical  was  missing — the  human  components. 

At  one  of  the  SIGCSE  workshops,  we  discussed  Massive 
Parallelism:  The  analogy  was  that  if  one  person  can  complete  a 
jigsaw  puzzle  in  two  hours,  two  people  could  possibly  do  it  in 
one.  Maybe  three  could  do  it  in  40  minutes.  However,  if  you  put 
the  entire  class  of  20  students  to  work  on  it,  it  would  probably 
take  three  or  four  hours.  Human  beings  do  not  parallelize  well. 
One  of  the  instructors  made  a  comment  that  Moore’s  Law 
applies  to  hardware  only — and  while  one  could  argue  that  it  takes 
1.8  years  to  double  software  capacity,  it  takes  18  years  to  double 
software  engineering  capabilities.  It’s  hard  to  significantly 
increase  human  capabilities.  My  feeling  is  that  as  newer  and 
newer  skills  and  languages  and  technologies  come,  older  knowl¬ 
edge  and  associated  skills  decrease.  And,  given  that  most  of  us 
support  the  DoD  in  some  way,  we  are  sometimes  working  with 
technology  that  was  developed  and  fielded  many  years  ago.  Face 
it:  We  need  “legacy”  skills  to  keep  older  systems  up  and  running. 

I  have  been  involved  in  education  and  training  for  more  than 
30  years.  I  have  taught  all  the  latest  trends  and  methodologies 
and  processes  as  they  develop  and  evolve.  However,  I  find  myself 
having  to  make  a  deep,  dark  confession:  I  am  still  teaching 
COBOL.  In  fact,  I  am  teaching  it  in  college  this  very  semester. 
Why?  Because  there  is  still  a  real  need  for  it  in  the  “real  world.” 
In  fact,  there  is  a  growing  need!  Mature  and  experienced  devel¬ 
opers  (that’s  a  nice  way  of  saying  “the  old  folks”)  are  retiring,  and 
large  companies  that  have  heavy  investments  in  older  languages 


over  the  years  need  new  developers  that  can  maintain  and  even 
expand  this  older  code. 

What  happens  when  the  current  (and  aging)  pool  of  devel¬ 
opers  of  legacy  code  dwindles,  and  fewer  and  fewer  newly  grad¬ 
uated  developers  know  how  to  maintain  older  systems?  Well, 
those  who  know  (or  are  willing  to  learn)  the  older  and  more  “tra¬ 
ditional”  languages  will  be  in  demand.  Like  that  old  Broadway 
song  says,  “everything  old  is  new  again”. 

While  working  on  this  column,  I  was  buying  an  online  ticket. 

The  Web  site  kept  rejecting  my  data  for  “unspec¬ 
ified  reasons.”  Eventually,  I  was  connected  to  one 
of  their  “application  specialists”  (short  for  devel¬ 
opers)  who  said  that  the  problem  was  that  my 
house  address  contains  the  fraction  “1/2”,  and 
their  application  could  not  handle  the  “/”.  I  jok- 
ingly  told  the  developer  “Oh,  storing  the  number 
in  a  PIC  9,  not  a  PIC  X,  huh?”  He  laughed — and 
asked  if  I  was  available  for  some  contract  work. 
Seems  they  have  a  hard  time  hiring  knowledgeable 
COBOL  developers.  If  this  anecdote — or,  for 
that  matter,  the  name  Grace  Murray  Hopper1 — 
doesn’t  register  with  you,  maybe  it’s  time  to  look 
again  at  those  “legacy”  languages. 

Remember,  there  are  no  old  languages — just 
job  opportunities. 

— David  A.  Cook,  Ph.D. 

Stephen  F.  Austin  State  University 
cookda@sfasu.edu 

Note 

1.  To  learn  more  about  RADM  Hopper  (1906-1992) — including 
her  role  in  COBOL — visit  <www.chips.navy.mil/links/ 
grace_hopper/womn.htm>.  As  stated  in  a  December  1999 
CROSSTALK  feature  called  Influential  Men  and  Women  of 
Software ,  she  was: 

...  creator  of  Common  Business  Oriented 
Language  (COBOL).  She  was  an  officer  in  the 
Navy  who  became  an  Admiral.  COBOL  came 
about  in  the  1 950s  when  the  need  for  higher  order 
languages  was  seen  as  a  way  to  increase  the  pro¬ 
ductivity  of  programming  computer  applications. 


Can  You  BACKTALK? 

Here  is  your  chance  to  make  your  point  without  your  boss 
censoring  your  writing.  In  addition  to  accepting  articles  that 
relate  to  software  engineering  for  publication  in  CROSSTALK, 
we  also  accept  articles  for  the  BACKTALK  column.  These  arti¬ 
cles  should  provide  a  concise,  clever,  humorous,  and  insight¬ 
ful  perspective  on  the  software  engineering  profession  or 
industry  or  a  portion  of  it.  Your  BACKTALK  article  should  be 
entertaining  and  clever  or  original  in  concept,  design,  or  deliv¬ 
ery,  and  should  not  exceed  750  words. 

For  more  information  on  how  to  submit  your  BACKTALK 
article,  go  to  <www.stsc.hill.af.mil>. 
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DEPARTMENT  OF  DEFENSE  SYSTEMS  ENGINEERING 

Delivering  Innovation,  Agility,  and  Speed 


Department  of  Defense  Systems  Engineering  applies  best  engineering  practices  to 

•  Support  the  current  fight;  manage  risk  with  discipline 

•  Grow  engineering  capabilities  to  address  emerging  challenges 

•  Champion  systems  engineering  as  a  tool  to  improve  acquisition  quality 

•  Develop  future  technical  leaders  across  the  acquisition  enterprise 


The  Department  of  Defense  seeks  experienced  engineers  dedicated  to  delivering 
technical  acquisition  excellence  for  the  warfighter.  See  wAvw.usajobs.gov 


Director  of  Systems  Engineering  •  Office  of  the  Director,  Defense  Research  and  Engineering 
3040  Defense  Pentagon  •  Washington,  DC  20301-3040  •  http://www.acq.osd.mil/se 
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